Messages in this thread | | | From | Jeremy Fitzhardinge <> | Subject | Re: [PATCH x86/mm 6/6] x86-64 ia32 ptrace get/putreg32 current task | Date | Sat, 1 Dec 2007 18:44:10 -0500 |
| |
On Nov 29, 2007, at 2:44 PM, Ingo Molnar wrote:
> > * Andi Kleen <andi@firstfloor.org> wrote: > >> For i386 iirc Jeremy/Zach did the benchmarking and they settled on >> %fs >> because it was faster for something (originally it was %gs too) > > yep. IIRC, some CPUs only optimize %fs because that's what Windows > uses > and leaves Linux with %gs out in the cold.
I did measure some anomalies with the AMD K6+ (or something like that), in which %gs was faster than %fs. It was pretty much inexplicable, but also unique - all other processors I tested (which was a range from Pentium MMX to current) had identical performance.
> There's also a performance > penalty for overlapping segment use, if the segment cache is single > entry only with an additional optimization for NULL [which just hides > the segment cache].
Some processors do perform slightly better with null selector loads than GDT/LDT ones, but it wasn't really noticeable for modern processors. The Intel architecture guy I asked about this said that it might be worth doing, but it would likely be swamped by a GDT cache miss. I looked at rearranging the kernel's GDT to pack all the kernel entry/exit entries into as few cachelines as possible, but it was surprisingly fiddley.
> But if it's good for unification we could switch that to %gs again on > 32-bit. I was one of the people who advocated the use of the 'other' > segment register, so that the hardware has less overlap, but clean and > unified code trumps this concern. It shouldnt be an issue on > reasonably > modern CPUs anyway.
Well, overall it should be fairly easy to make the two arches use their own segment registers with a simple #define. But things like ptrace and vm86 were tricky, though I guess the latter isn't an issue for 64-bit.
I originally chose %gs for the kernel, partly in the hope that compiler support for TLS would be helpful in the kernel, though that doesn't seem like a good idea in retrospect. %gs for the sake of consistency would be reasonable, and wouldn't have a measurable downside.
J
| |