lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 15 Dec 2020 09:56:45 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     Tony W Wang-oc <TonyWWang-oc@...oxin.com>
Cc:     herbert@...dor.apana.org.au, davem@...emloft.net,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, x86@...nel.org,
        hpa@...or.com, linux-crypto@...r.kernel.org,
        linux-kernel@...r.kernel.org, TimGuo-oc@...oxin.com,
        CooperYan@...oxin.com, QiyuanWang@...oxin.com,
        HerryYang@...oxin.com, CobeChen@...oxin.com, SilviaZhao@...oxin.com
Subject: Re: [PATCH] crypto: x86/crc32c-intel - Don't match some Zhaoxin CPUs

On Tue, Dec 15, 2020 at 10:15:29AM +0800, Tony W Wang-oc wrote:
> 
> On 15/12/2020 04:41, Eric Biggers wrote:
> > On Mon, Dec 14, 2020 at 10:28:19AM +0800, Tony W Wang-oc wrote:
> >> On 12/12/2020 01:43, Eric Biggers wrote:
> >>> On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
> >>>> The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
> >>>> On platforms with Zhaoxin CPUs supporting this X86 feature, When
> >>>> crc32c-intel and crc32c-generic are both registered, system will
> >>>> use crc32c-intel because its .cra_priority is greater than
> >>>> crc32c-generic. This case expect to use crc32c-generic driver for
> >>>> some Zhaoxin CPUs to get performance gain, So remove these Zhaoxin
> >>>> CPUs support from crc32c-intel.
> >>>>
> >>>> Signed-off-by: Tony W Wang-oc <TonyWWang-oc@...oxin.com>
> >>>
> >>> Does this mean that the performance of the crc32c instruction on those CPUs is
> >>> actually slower than a regular C implementation?  That's very weird.
> >>>
> >>
> >> From the lmbench3 Create and Delete file test on those chips, I think yes.
> >>
> > 
> > Did you try measuring the performance of the hashing itself, and not some
> > higher-level filesystem operations?
> > 
> 
> Yes. Was testing on these Zhaoxin CPUs, the result is that with the same
> input value the generic C implementation takes fewer time than the
> crc32c instruction implementation.
> 

And that is really "working as intended"?  Why do these CPUs even declare that
they support the crc32c instruction, when it is so slow?

Are there any other instruction sets (AES-NI, PCLMUL, SSE, SSE2, AVX, etc.) that
these CPUs similarly declare support for but they are uselessly slow?

- Eric

Powered by blists - more mailing lists