Re: [RFC PATCH] x86: optimize IRET returns to kernel

[Andy Lutomirski]

On Tue, Mar 31, 2015 at 5:46 AM, Denys Vlasenko <dvlasenk@xxxxxxxxxx> 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

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.  Your patch
may need that.  Sadly, this may kill any attempt to completely prevent
NMI nesting.

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.

This should dramatically speed up in-kernel page faults as well as IRQ
handling from kernel mode.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/