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@xxxxxxxxxxxxxxxxxx>: >>> >>> 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. >> >
