Re: [PATCH] 3/5 explicit-iopl

[Andi Kleen <ak@suse.de>]

> Well... maybe.  On Opteron and/or Intel EMT it may not be a win.  The 
> cost of the branch could overtake the cost of the POPF (that's the 
> expensive one).  Grrr.

Not on Opteron, but probably on Intel.

iirc popf will actually flush parts of the trace cache, while
a branch shouldn't do that. So I expect it to be a win.


> 
> >Can we perhaps get rid of the PUSHF/POPF in the SYSENTER syscall path too?
> >iirc they were only for single stepping. But SYSENTER doesn't disable
> >single stepping, so the debug handler could detect this and set
> >some magic flag that restores it on syscall exit.
> > 
> >
> 
> A context switch requires IRET, which requires the flags to be saved, so 
> you can't eliminate the pushf (*) IIRC, the popf is already omitted.  

If we have iopl and TF elsewhere then the flags could just be replaced
with a default value. 

Drawback would be that it would be slightly incompatible to before,
but then it's just a function call and function calls are not 
required to preserve flags.

> (*) Well, you could.  It's just that system calls would have to clobber 
> flags - hmm.. sysenter based calls already do. But I'm not 100% sure 

They do pushf. 

> there isn't some bogon case where kernel preemption could cause you a 
> problem.  Keeping around the fake IRET frame still appears to be a good 
> thing to do just for the benefit of ptrace / debug functionality.  PUSHF 
> is cheap on every core I have measured on.

Are you sure? I thought it was expensive on Northwood at least.
Haven't measured on a Prescott or newer.

-Andi