summaryrefslogtreecommitdiff
path: root/crt/mips
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2021-08-12 18:07:44 -0400
committerRich Felker <dalias@aerifal.cx>2021-08-12 18:07:44 -0400
commitb713b8b2e4b9595eec72ec3c4fe7714076d60478 (patch)
tree91f0bdf5a3ff135e842be18f2e0081659d2e95f9 /crt/mips
parent3eed6a6f0a400763313bc5dca6e3b22a75166dbe (diff)
downloadmusl-b713b8b2e4b9595eec72ec3c4fe7714076d60478.tar.gz
fix excessively slow TLS performance on some mips models
commit 6d99ad91e869aab35a4d76d34c3c9eaf29482bad introduced this regression as part of a larger change, based on an incorrect assumption that rdhwr being part of the mips r2 ISA level meant that the TLS register, known in the mips documentation as UserLocal, was unconditionally present on chips providing this ISA level and would not need trap-and-emulate. this turns out to be false. based on research by Stanislav Kljuhhin and Abilio Marques, who reported the problem as a performance regression on certain routers using OpenWRT vs older uclibc-based versions, it turns out the mips manuals document the UserLocal register as a feature that might or might not be implemented or enabled, reflected by a cpu capability bit in the CONFIG3 register, and that Linux checks for this and has to explicitly enable it on models that have it. thus, it's indeed possible that r2+ chips can lack the feature, bringing us back to the situation where Linux only has a fast trap-and-emulate path for the case where the destination register is $3. so, always read the thread pointer through $3. this may incur a gratuitous move to the desired final register on chips where it's not needed, but it really doesn't matter.
Diffstat (limited to 'crt/mips')
0 files changed, 0 insertions, 0 deletions