[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190405215520.wsevtopb63oetkfd@treble>
Date: Fri, 5 Apr 2019 16:55:20 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Andy Lutomirski <luto@...nel.org>,
Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [patch V2 20/29] x86/dumpstack/64: Speedup in_exception_stack()
On Fri, Apr 05, 2019 at 05:07:18PM +0200, Thomas Gleixner wrote:
> The current implementation of in_exception_stack() iterates over the
> exception stacks array. Most of the time this is an useless exercise, but
> even for the actual use cases (perf and ftrace) it takes at least 2
> iterations to get to the NMI stack.
>
> As the exception stacks and the guard pages are page aligned the loop can
> be avoided completely.
>
> Add a initial check whether the stack pointer is inside the full exception
> stack area and leave early if not.
>
> Create a lookup table which describes the stack area. The table index is
> the page offset from the beginning of the exception stacks. So for any
> given stack pointer the page offset is computed and a lookup in the
> description table is performed. If it is inside a guard page, return. If
> not, use the descriptor to fill in the info structure.
>
> The table is filled at compile time and for the !KASAN case the interesting
> page descriptors exactly fit into a single cache line. Just the last guard
> page descriptor is in the next cacheline, but that should not be accessed
> in the regular case.
>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> ---
> V2: Simplify the macro maze
This is indeed a little better. It's friday, have an ack.
Acked-by: Josh Poimboeuf <jpoimboe@...hat.com>
I don't like the clever ISTACK_* macro naming however...
--
Josh
Powered by blists - more mailing lists