lkml.org 
[lkml]   [2007]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH x86/mm 6/6] x86-64 ia32 ptrace get/putreg32 current task
Date

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


\
 
 \ /
  Last update: 2007-12-02 00:49    [W:0.061 / U:0.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site