> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |