Hi, On Thu, May 24, 2018 at 11:01:20AM +0300, Timofey Titovets wrote: > ср, 23 мая 2018 г. в 17:24, Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>: > > > Hi Timofey, [ ... ] > > It really feels wrong to keep choice_fastest_hash() in fasthash(), it is > > done only once and really belongs to the init function, like ksm_init(). > As > > That possible to move decision from lazy load, to ksm_thread, > that will allow us to start bench and not slowdown boot. > > But for that to works, ksm must start later, after init of crypto. What about moving choice_fastest_hash() to run_store()? KSM anyway starts with ksm_run = KSM_RUN_STOP and does not scan until userspace writes !0 to /sys/kernel/mm/ksm/run. Selection of the hash function when KSM is actually enabled seems quite appropriate... > > I understand, you think it is a bad idea to keep it in ksm_init() because > > it slows down boot by 0.25s, which I agree with your is substantial. But, > I > > really do not think that we should spend those 0.25s at all deciding what > > hash function is optimal, and instead default to one or another during > boot > > based on hardware we are booting on. If crc32c without hw acceleration is > > no worse than jhash2, maybe we should simply switch to crc32c? > > crc32c with no hw, are slower in compare to jhash2 on x86, so i think on > other arches result will be same. > > > Thank you, > > Pavel > > Thanks. > > -- > Have a nice day, > Timofey. > -- Sincerely yours, Mike.
