> 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/
