From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by kanga.kvack.org (Postfix) with ESMTP id 543A48E0002 for ; Thu, 13 Sep 2018 14:01:46 -0400 (EDT) Received: by mail-oi0-f69.google.com with SMTP id l14-v6so6998494oii.9 for ; Thu, 13 Sep 2018 11:01:46 -0700 (PDT) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com. [148.163.158.5]) by mx.google.com with ESMTPS id b42-v6si695768otd.72.2018.09.13.11.01.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 11:01:44 -0700 (PDT) Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8DHsLjq011635 for ; Thu, 13 Sep 2018 14:01:43 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0b-001b2d01.pphosted.com with ESMTP id 2mfvaa9476-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 13 Sep 2018 14:01:41 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 13 Sep 2018 19:01:39 +0100 Date: Thu, 13 Sep 2018 21:01:33 +0300 From: Mike Rapoport Subject: Re: [PATCH V6 2/2 RESEND] ksm: replace jhash2 with faster hash References: <20180527130325.GB4522@rapoport-lnx> <20180607115232.GA8245@rapoport-lnx> <20180625084806.GB13791@rapoport-lnx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Message-Id: <20180913180132.GB15191@rapoport-lnx> Sender: owner-linux-mm@kvack.org List-ID: To: Timofey Titovets Cc: Pasha Tatashin , linux-mm@kvack.org, Sioh Lee , Andrea Arcangeli , kvm@vger.kernel.org (updated Pasha's e-mail) Thu, Sep 13, 2018 at 01:35:20PM +0300, Timofey Titovets wrote: > D?D 1/2 , 25 D,N?D 1/2 . 2018 D3. D2 11:48, Mike Rapoport : > > > > 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 > > crc32c_intel: 1084.10ns > > crc32c (no hardware acceleration): 7012.51ns > > xxhash32: 2227.75ns > > xxhash64: 1413.16ns > > jhash2: 5128.30ns > > -- > Have a nice day, > Timofey. > -- Sincerely yours, Mike.