Re: [PATCH V6 2/2 RESEND] ksm: replace jhash2 with faster hash

From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Timofey Titovets <nefelim4ag@gmail.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	solee@os.korea.ac.kr, aarcange@redhat.com, kvm@vger.kernel.org
Subject: Re: [PATCH V6 2/2 RESEND] ksm: replace jhash2 with faster hash
Date: Sun, 10 Jun 2018 08:38:39 +0300	[thread overview]
Message-ID: <20180610053838.GB20681@rapoport-lnx> (raw)
In-Reply-To: <CAGM2rebK=gNbcAwkmt7W9kwtd=QWoPRogQMaoXOv=bmX+_d+yw@mail.gmail.com>

On Thu, Jun 07, 2018 at 09:29:49PM -0400, Pavel Tatashin wrote:
> > With CONFIG_SYSFS=n there is nothing that will set ksm_run to anything but
> > zero and ksm_do_scan will never be called.
> >
> 
> Unfortunatly, this is not so:
> 
> In: /linux-master/mm/ksm.c
> 
> 3143#else
> 3144 ksm_run = KSM_RUN_MERGE; /* no way for user to start it */
> 3145
> 3146#endif /* CONFIG_SYSFS */
> 
> So, we do set ksm_run to run right from ksm_init() when CONFIG_SYSFS=n.

Huh, missed that one...

> I wonder if this is acceptible to only use xxhash when CONFIG_SYSFS=n ?

A bit unrelated to CONFIG_SYSFS, but rather for rare use-cases in general.
What will happen in the following scenario:

* The system has crc32c HW acceleration
* KSM chooses crc32c
* KSM runs with crc32c
* user removes crc32c HW acceleration module

If I understand correctly, we'll then fall back to pure SW crc32c
calculations, right?

> Thank you,
> Pavel
> 

-- 
Sincerely yours,
Mike.