Messages in this thread | | | From | Noah Goldstein <> | Date | Fri, 15 Oct 2021 12:30:42 -0500 | Subject | Re: [PATCH v1] x86/fpu: Remove opmask state from avx512_timestamp check |
| |
On Fri, Oct 15, 2021 at 10:25 AM Dave Hansen <dave.hansen@intel.com> wrote: > > On 10/14/21 8:49 AM, Noah Goldstein wrote: > > Irrelevant of the still existing flaws, it makes the output more accurate. > > > > Is there a cost to the change I am not seeing? > > We'd want to make sure that this doesn't break anything. It probably > won't, but it theoretically could. > > For instance, if someone was doing: > > avx512_foo(); > xsave->xstate_bv &= ~XFEATURE_MASK_ZMMS; > XRSTOR(xsave, -1); > > That would leave the opmask in place, but would lead to the ZMM > registers tracked as being in their init state.
The 'XFEATURE_MASK_ZMMS' is new to this patch so I don't think this patch could be adding that issue.
> > This would be *very* unlikely, but it would be great if Aubrey (the > original avx512_timestamp patch author) could make sure that it doesn't > break anything. > > Also, there's the side issue of AVX-256 use. AVX-256 uses the ZMM > registers which are a part of XFEATURE_MASK_AVX512, but does not incur > the same frequency penalties of the full 512-bit-wide instructions. > Since ZMM_Hi256 is the *only* ZMM state which is truly 512-bit-only, we > could argue that it's the only one we should consider. > > Noah, thanks for bringing this up. I'm not opposed to your patch, but > let's just make sure that it doesn't break anything and also that we > shouldn't do a bit more at the same time (ignore Hi16_ZMM for > avx512_timestamp).
I think that may make sense. Or outputting separate timestamps for both. Especially because in GLIBC we have moved to preferring EVEX implementings for all x86_64 string functions because vzeroupper aborts RTM transactions: https://sourceware.org/bugzilla/show_bug.cgi?id=27457
So if an application is using GLIBC on an avx512 machine most likely the avx512 indicator will be permanently set.
| |