Messages in this thread | | | From | Andy Lutomirski <> | Date | Sat, 4 Apr 2015 09:54:40 -0700 | Subject | Re: [RFC PATCH] x86: optimize IRET returns to kernel |
| |
On Tue, Mar 31, 2015 at 8:59 AM, Denys Vlasenko <dvlasenk@redhat.com> wrote: > On 03/31/2015 03:54 PM, Andy Lutomirski wrote: >> On Tue, Mar 31, 2015 at 5:46 AM, Denys Vlasenko <dvlasenk@redhat.com> wrote: >>> This is not proposed to be merged yet. >>> >>> Andy, this patch is in spirit of your crazy ideas of repurposing >>> instructions for the roles they weren't intended for :) >>> >>> Recently I measured IRET timings and was newly "impressed" >>> how slow it is. 200+ cycles. So I started thinking... >>> >>> When we return from interrupt/exception *to kernel*, >>> most of IRET's doings are not necessary. CS and SS >>> do not need changing. And in many (most?) cases >>> saved RSP points right at the top of pt_regs, >>> or (top of pt_regs+8). >>> >>> In which case we can (ab)use POPF and RET! >>> >>> Please see the patch. >> >> I have an old attempt at this here: >> >> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=fast-return-to-kernel&id=6cfe29821979c42cd812878e05577f69f99fafaf > > Your version is better :/ > > I'd only suggest s/pop %rsp/mov (%rsp),%rsp/ > > I suspect "pop %rsp" is not an easy insn for CPU to digest. > >> If I were doing it again, I'd add a bit more care: if saved eflags >> have RF set (can kgdb do that?), then we have to use iret. > > Good idea, we can even be paranoid and jump to real IRET if any > of "unusual" flags are set. > >> I think that, if returning to IF=1, you need to do sti;ret to avoid an >> infinite stack usage failure in which, during an IRQ storm, each IRQ >> adds around one word of stack utilization because you haven't done the >> ret yet before the next IRQ comes in. To make that robust, I'd adjust >> the NMI code to clear IF and back up one instruction if it interrupts >> after sti. > > I kinda hoped POPF is secretly a shadowing insn too. > Experiments show it is not. >
I'll fiddle with this some more at some point. First I want to get rid of IST for #DB and #BP, which will reduce the number of funny cases to think about. I hope to have patches for that ready short after the next merge window closes.
-- Andy Lutomirski AMA Capital Management, LLC
| |