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

[Pasha Tatashin <Pavel.Tatashin@microsoft.com>]

On 9/13/18 2:01 PM, Mike Rapoport wrote:
> (updated Pasha's e-mail)
> 
> Thu, Sep 13, 2018 at 01:35:20PM +0300, Timofey Titovets wrote:
>> пн, 25 июн. 2018 г. в 11:48, Mike Rapoport <rppt@linux.vnet.ibm.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.
>>>>
>>>> I wonder if this is acceptible to only use xxhash when CONFIG_SYSFS=n ?
>>>
>>> BTW, with CONFIG_SYSFS=n KSM may start running before hardware acceleration
>>> for crc32c is initialized...
>>>
>>>> Thank you,
>>>> Pavel
>>>>
>>>
>>> --
>>> Sincerely yours,
>>> Mike.
>>>
>>
>> Little thread bump.
>> That patchset can't move forward already for about ~8 month.
>> As i see main question in thread: that we have a race with ksm
>> initialization and availability of crypto api.
>> Maybe we then can fall back to simple plan, and just replace old good
>> buddy jhash by just more fast xxhash?
>> That allow move question with crypto api & crc32 to background, and
>> make things better for now, in 2-3 times.
>>
>> What you all think about that?
> 
> Sounds reasonable to me

Same here, please send a new patch with xxhash, and after that we can
work on a faster crc32.

Thank you,
Pavel

> 
>>> crc32c_intel: 1084.10ns
>>> crc32c (no hardware acceleration): 7012.51ns
>>> xxhash32: 2227.75ns
>>> xxhash64: 1413.16ns
>>> jhash2: 5128.30ns
>>
>> -- 
>> Have a nice day,
>> Timofey.
>>
>