Re: [BENCHMARK] Lmbench 2.5.54-mm2 (impressive improvements)

[Linus Torvalds]

On 5 Jan 2003, Andi Kleen wrote:
> 
> Regarding the EFLAGS handling: why can't you just do 
> a pushfl in the vsyscall page before pushing the 6th arg on the stack
> and a popfl afterwards. 

I did that originally, but timings from Jamie convinced me that it's 
actually a quite noticeable overhead for the system call path.

You should realize that the 5-9% slowdown in schedule (which I don't like)  
comes with a 360% speedup on a P4 in simple system call handling (which I
_do_ like). My P4 does a system call in 428 cycles as opposed to 1568
cycles according to my benchmarks.

And part of the reason for the huge speedup is that the vsyscall/sysenter
path is actually pretty much the fastest possible. Yes, it would have been
faster just from using sysenter/sysexit, but not by 360%. The other
speedups come from not reloading segment registers multiple times
(noticeable on a PIII, not a P4) and from avoiding things liek the flags
pushing.

NOTE! We could trivially speed up the task switching by making 
"load_esp0()" a bit smarter. Right now it actually re-writes _both_ 
SYSENTER_CS and SYSENTER_ESP on a taskswitch, and that's because a process 
that was in vm86 mode will have cleared SYSENTER_CS (so that sysenter will 
cause a GP fault inside vm86 mode).

Now, that SYSENTER_CS thing is very rare indeed, and by keeping track of 
what the previous value was (ie just caching the SYSENTER_CS value in the 
thread_struct), we could get rid of it with a conditional jump instead. 
Want to try it?

> This would also eliminate the random IOPL problem Luca noticed.

Nope, it wouldn't. A "popfl" in user mode does nothing for iopl. You have 
to have the popfl in kernel mode.

			Linus