[lkml]   [2005]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] 3/5 explicit-iopl
> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-04 17:55    [W:0.034 / U:2.320 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site