From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 443BF3898539; Mon, 1 Mar 2021 13:24:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 443BF3898539 From: "hjl.tools at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug string/27457] vzeroupper use in AVX2 multiarch string functions cause HTM aborts Date: Mon, 01 Mar 2021 13:24:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: string X-Bugzilla-Version: 2.31 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hjl.tools at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: hjl.tools at gmail dot com X-Bugzilla-Target-Milestone: 2.34 X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 13:24:24 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27457 --- Comment #11 from H.J. Lu --- (In reply to Florian Weimer from comment #9) > (In reply to rguenther from comment #7) > > On Mon, 1 Mar 2021, fweimer at redhat dot com wrote: > > > The sources do not seem to show the selection logic. > > > __memset_avx2_unaligned_rtm seems to simply have dropped the VZEROUPP= ER > > > instruction, which can't be good for general application performance. > >=20 > > The intent was to use %ymm16+ only which does not cause any transition > > penalty even w/o vzeroupper. >=20 > I still saw %ymm0 usage in the disassembly, if I recall correctly. And for > AVX2, there isn't much choice. I didn't try to reverse-engineer the > corresponding IFUNC selector. At function exit, there is f3: 0f 01 d6 xtest=20=20 f6: 74 04 je fc <__memset_avx2_unaligned_erms_rtm+0x5c> f8: c5 fc 77 vzeroall=20 fb: c3 ret=20=20=20=20 fc: c5 f8 77 vzeroupper=20 ff: c3 ret=20=20=20=20 > > There's the option to use another path when HTM is available, doing > > xtest and branch to the non-AVX variants when a transaction is active. > > I'm not sure about the overhead of xtest here. Nor am I sure whether > > Intel has (or plans any) SKUs with HTM but not AVX512. Since HTM > > on broadwell + haswell is crippled due to bugs (and thus usually > > disabled in firmware) this leaves Skylake and later where I don't > > know of any HTM but no-AVX512 SKUs. But this is Intel, so ... >=20 > Skylake is an overloaded term. There is e.g. Xeon E3-1240 v5 which is > advertised as having the Skylake microarchitecture, but it doesn't have > AVX-512. (I haven't checked RTM status, but I don't see why it wouldn't be > supported.) Xeon E3-1240 v6 is Kaby Lake, but it doesn't have AVX-512 > either, and according to what I see, RTM is not disabled by at least one > current distribution kernel/microcode combination. >=20 > But I think the gist is that RTM without AVX-512 exists out there even in > server parts. It is handed by #define ZERO_UPPER_VEC_REGISTERS_RETURN \ ZERO_UPPER_VEC_REGISTERS_RETURN_XTEST --=20 You are receiving this mail because: You are on the CC list for the bug.=