aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorThomas Gleixner <[email protected]>2019-04-14 17:59:58 +0200
committerBorislav Petkov <[email protected]>2019-04-17 15:16:57 +0200
commitc450c8f532b63475b30e29bc600c25ab0a4ab282 (patch)
tree22f36425a4e720fca3216f6b2c129d3a078d5f1e /tools/perf/scripts/python/export-to-postgresql.py
parent2a594d4ccf3f10f80b77d71bd3dad10813ac0137 (diff)
x86/dumpstack/64: Speedup in_exception_stack()
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 <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Sean Christopherson <[email protected]> Cc: x86-ml <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions