lkml.org 
[lkml]   [2015]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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


\
 
 \ /
  Last update: 2015-04-04 19:01    [W:0.033 / U:3.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site