linux-kernel - RE: Why does glibc use AVX-512?

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 linux-cve-announce 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]

Message-ID: <5cb200606c5c40d4a289dbc6ad08f437@AcuMS.aculab.com>
Date:   Fri, 26 Mar 2021 13:32:31 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Andy Lutomirski' <luto@...nel.org>,
        libc-alpha <libc-alpha@...rceware.org>,
        "H. J. Lu" <hjl.tools@...il.com>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        Florian Weimer <fweimer@...hat.com>,
        "Carlos O'Donell" <carlos@...hat.com>,
        Rich Felker <dalias@...c.org>
Subject: RE: Why does glibc use AVX-512?

From: Andy Lutomirski
> Sent: 26 March 2021 04:38
> 
> Hi all-
> 
> glibc appears to use AVX512F for memcpy by default.  (Unless
> Prefer_ERMS is default-on, but I genuinely can't tell if this is the
> case.  I did some searching.)  The commit adding it refers to a 2016
> email saying that it's 30% on KNL.  Unfortunately, AVX-512 is now
> available in normal hardware, and the overhead from switching between
> normal and AVX-512 code appears to vary from bad to genuinely
> horrible.  And, once anything has used the high parts of YMM and/or
> ZMM, those states tend to get stuck with XINUSE=1.

Yes I wonder how much faster 'normal' copies ever get because
of these optimisations.
Not many programs sit in a loop repeatedly copying the same 8k buffer.

Not to mention the cpu where the 'wide' instructions either
use the 'narrow' execution unit twice or at half frequency.
So while supported, using them isn't really useful.

IIRC the [XYZ]MM registers are all caller saved?
So system calls (or rather the C wrapper) is allowed to
trash them all.
So the system call entry could zero all the [XYZ]MM registers.
I think they XSAVExxx and later XRESTORExxx are then quick.
In particular they don't need saving on a context switch from
a system call.
This might get them marked 'not in use' more often.
But probably not if memcpy() starts using them.
(This doesn't help signal handlers.)

ISTR one cpu family where ZVEROUPPER goes from 'cheap' to
'expensive'.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)