[PATCH 0/4] i386 - pte update optimizations

[PATCH 0/4] i386 - pte update optimizations

[Zachary Amsden]

Some PTE optimizations for native and paravirt-ops kernels; this
provides a huge win for shadow mode hypervisors and gets rid of
some unnecessary atomic instructions in native kernels, saving
even more on UP by getting rid of implicit LOCK on xchg instruction.

Zach

Re: [PATCH 0/4] i386 - pte update optimizations

[H. Peter Anvin]

Zachary Amsden wrote:
> Some PTE optimizations for native and paravirt-ops kernels; this
> provides a huge win for shadow mode hypervisors and gets rid of
> some unnecessary atomic instructions in native kernels, saving
> even more on UP by getting rid of implicit LOCK on xchg instruction.

You do know that P6 and higher don't do locked bus references as long as 
the value is in the cache, right?

	-hpa

Re: [PATCH 0/4] i386 - pte update optimizations

[Zachary Amsden]

H. Peter Anvin wrote:
> Zachary Amsden wrote:
>> Some PTE optimizations for native and paravirt-ops kernels; this
>> provides a huge win for shadow mode hypervisors and gets rid of
>> some unnecessary atomic instructions in native kernels, saving
>> even more on UP by getting rid of implicit LOCK on xchg instruction.
>
> You do know that P6 and higher don't do locked bus references as long 
> as the value is in the cache, right?

Yes.  Even then, last time I clocked instructions, xchg was still slower 
than read / write, although I could be misremembering.  And it's not 
totally clear that they will always be in cached state, however, and for 
SMP, we still want to drop the implicit lock in cases where the 
processor might not know they are cached exclusive, but we know there 
are no other racing users.  And there are plenty of old processors out 
there to still make it worthwhile.

Zach

Re: [PATCH 0/4] i386 - pte update optimizations

[Eric Dumazet]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

Zachary Amsden a écrit :
> 
> Yes.  Even then, last time I clocked instructions, xchg was still slower 
> than read / write, although I could be misremembering.  And it's not 
> totally clear that they will always be in cached state, however, and for 
> SMP, we still want to drop the implicit lock in cases where the 
> processor might not know they are cached exclusive, but we know there 
> are no other racing users.  And there are plenty of old processors out 
> there to still make it worthwhile.
> 

Is there one processor that benefit from this patch then ?

I couldnt get a win on my test machines, maybe they are not old enough ;)

umask() doesnt need xchg() atomic semantic. If several threads are using 
umask() concurrently results are not guaranted anyway.

[-- Attachment #2: umask.patch --]
[-- Type: text/plain, Size: 441 bytes --]

--- linux-2.6.21-rc6/kernel/sys.c
+++ linux-2.6.21-rc6-ed/kernel/sys.c
@@ -2138,8 +2138,10 @@ asmlinkage long sys_getrusage(int who, s
 
 asmlinkage long sys_umask(int mask)
 {
-	mask = xchg(&current->fs->umask, mask & S_IRWXUGO);
-	return mask;
+	struct fs_struct *fs = current->fs;
+	int old = fs->umask;
+	fs->umask = mask & S_IRWXUGO;
+	return old;
 }
     
 asmlinkage long sys_prctl(int option, unsigned long arg2, unsigned long arg3,

Re: [PATCH 0/4] i386 - pte update optimizations

[H. Peter Anvin]

Eric Dumazet wrote:
> 
> Is there one processor that benefit from this patch then ?
> 

At least P5 systems should benefit.

	-hpa

Re: [PATCH 0/4] i386 - pte update optimizations

[Keir Fraser]

On 13/4/07 03:24, "Zachary Amsden" <zach@vmware.com> wrote:

>> You do know that P6 and higher don't do locked bus references as long
>> as the value is in the cache, right?
> 
> Yes.  Even then, last time I clocked instructions, xchg was still slower
> than read / write, although I could be misremembering.  And it's not
> totally clear that they will always be in cached state, however, and for
> SMP, we still want to drop the implicit lock in cases where the
> processor might not know they are cached exclusive, but we know there
> are no other racing users.  And there are plenty of old processors out
> there to still make it worthwhile.

LOCKed instruction suck really badly on the netburst microarchitecture (like
factor of 10x, or not far off). I think it's probably because of their side
effect of serialising memory accesses, causing horrible pipeline stalls.

 -- Keir

Re: [PATCH 0/4] i386 - pte update optimizations

[Keir Fraser]

On 13/4/07 13:27, "Andi Kleen" <andi@firstfloor.org> wrote:

>> LOCKed instruction suck really badly on the netburst microarchitecture (like
>> factor of 10x, or not far off). I think it's probably because of their side
>> effect of serialising memory accesses, causing horrible pipeline stalls.
> 
> Unfortunately they tend to be HyperThreaded usually (except for early ones
> and Celerons) and need the LOCK anyways.

Fair point, although quite a few people disable HT.

 -- Keir

Re: [PATCH 0/4] i386 - pte update optimizations

[Andi Kleen]

Keir Fraser <keir@xensource.com> writes:

> On 13/4/07 03:24, "Zachary Amsden" <zach@vmware.com> wrote:
> 
> >> You do know that P6 and higher don't do locked bus references as long
> >> as the value is in the cache, right?
> > 
> > Yes.  Even then, last time I clocked instructions, xchg was still slower
> > than read / write, although I could be misremembering.  And it's not
> > totally clear that they will always be in cached state, however, and for
> > SMP, we still want to drop the implicit lock in cases where the
> > processor might not know they are cached exclusive, but we know there
> > are no other racing users.  And there are plenty of old processors out
> > there to still make it worthwhile.
> 
> LOCKed instruction suck really badly on the netburst microarchitecture (like
> factor of 10x, or not far off). I think it's probably because of their side
> effect of serialising memory accesses, causing horrible pipeline stalls.

Unfortunately they tend to be HyperThreaded usually (except for early ones 
and Celerons) and need the LOCK anyways.

-Andi

Re: [PATCH 0/4] i386 - pte update optimizations

[H. Peter Anvin]

Keir Fraser wrote:
> On 13/4/07 13:27, "Andi Kleen" <andi@firstfloor.org> wrote:
> 
>>> LOCKed instruction suck really badly on the netburst microarchitecture (like
>>> factor of 10x, or not far off). I think it's probably because of their side
>>> effect of serialising memory accesses, causing horrible pipeline stalls.
>> Unfortunately they tend to be HyperThreaded usually (except for early ones
>> and Celerons) and need the LOCK anyways.
> 
> Fair point, although quite a few people disable HT.

Note we're talking a UP-only hack.

	-hpa