* Andy Lutomirski: > On Fri, Mar 26, 2021 at 1:35 PM Florian Weimer <f...@deneb.enyo.de> wrote: >> >> * Andy Lutomirski: >> >> > On Fri, Mar 26, 2021 at 12:34 PM Florian Weimer <f...@deneb.enyo.de> wrote: >> >> x86: Sporadic failures in tst-cpu-features-cpuinfo >> >> <https://sourceware.org/bugzilla/show_bug.cgi?id=27398#c3> >> > >> > It's worth noting that recent microcode updates have make RTM >> > considerably less likely to actually work on many parts. It's >> > possible you should just disable it. :( >> >> Sorry, I'm not sure who should disable it. >> >> Let me sum up the situation: >> >> We have a request for a performance enhancement in glibc, so that >> applications can use it on server parts where RTM actually works. >> >> For CPUs that support AVX-512, we may be able to meet that with a >> change that uses the new 256-bit registers, t avoid the %xmm >> transition penalty. (This is the easy case, hopefully—there shouldn't >> be any frequency issues associated with that, and if the kernel >> doesn't optimize the context switch today, that's a nonissue as well.) > > I would make sure that the transition penalty actually works the way > you think it does. My general experience with the transition > penalties is that the CPU is rather more aggressive about penalizing > you than makes sense.
Do you mean the frequency/thermal budget? I mean the immense slowdown you get if you use %xmm registers after their %ymm counterparts (doesn't have to be %zmm, that issue is present starting with AVX) and you have not issued VZEROALL or VZEROUPPER between the two uses. It's a bit like EMMS, I gues, only that you don't get corruption, just really poor performance. >> For CPUs that do not support AVX-512 but support RTM (and AVX2), we >> need a dynamic run-time check whether the string function is invoked >> in a transaction. In that case, we need to use VZEROALL instead of >> VZEROUPPER. (It's apparently too costly to issue VZEROALL >> unconditionally.) > > So VZEROALL works in a transaction and VZEROUPPER doesn't? That's bizarre. Apparently yes. >> All this needs to work transparently without user intervention. We >> cannot require firmware upgrades to fix the incorrect RTM reporting >> issue (the bug I referenced). I think we can require software updates >> which tell glibc when to use RTM-enabled string functions if the >> dynamic selection does not work (either for performance reasons, or >> because of the RTM reporting bug). >> >> I want to avoid a situation where one in eight processes fail to work >> correctly because the CPUID checks ran on CPU 0, where RTM is reported >> as available, and then we trap when executing XTEST on other CPUs. > > What kind of system has that problem? It's a standard laptop after a suspend/resume cycle. It's either a kernel or firmware bug. > If RTM reports as available, then it should work in the sense of not > trapping. (There is no guarantee that transactions will *ever* > complete, and that part is no joke.) XTEST doesn't abort transactions, but it traps without RTM support. If CPU0 has RTM support and we enable XTEST use in glibc based on that (because the startup code runs on CPU0), then the XTEST instruction must not trap when running on other CPUs. Currently, we do not use RTM for anything in glibc by default, even if it is available according to CPUID. (There are ways to opt in, unless the CPU is on the disallow list due to the early Haswell bug.) I'm worried that if we start executing XTEST on all CPUs that indicate RTM support, we will see lots of weird issues, along the lines of bug 27398.
