mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: peterz@infradead.org
Cc: dave@sr71.net, linux-kernel@vger.kernel.org, mingo@kernel.org,
	eranian@google.com, x86@kernel.org,
	Andi Kleen <ak@linux.intel.com>
Subject: [PATCH 1/2] Use faster check for modules in backtrace on 64bit
Date: Fri, 26 Sep 2014 16:31:16 -0700	[thread overview]
Message-ID: <1411774277-4198-2-git-send-email-andi@firstfloor.org> (raw)
In-Reply-To: <1411774277-4198-1-git-send-email-andi@firstfloor.org>

From: Andi Kleen <ak@linux.intel.com>

On my workstation which has a lot of modules loaded:

$ lsmod | wc -l
80

backtrace from the NMI for perf record -g can take a quite long time.

This leads to frequent messages like:
perf interrupt took too long (7852 > 7812), lowering kernel.perf_event_max_sample_rate to 16000

One larger part of the PMI cost is each text address check during
the backtrace taking upto to 3us, like this:

  1)               |          print_context_stack_bp() {
  1)               |            __kernel_text_address() {
  1)               |              is_module_text_address() {
  1)               |                __module_text_address() {
  1)   1.611 us    |                  __module_address();
  1)   1.939 us    |                }
  1)   2.296 us    |              }
  1)   2.659 us    |            }
  1)               |            __kernel_text_address() {
  1)               |              is_module_text_address() {
  1)               |                __module_text_address() {
  1)   0.724 us    |                  __module_address();
  1)   1.064 us    |                }
  1)   1.430 us    |              }
  1)   1.798 us    |            }
  1)               |            __kernel_text_address() {
  1)               |              is_module_text_address() {
  1)               |                __module_text_address() {
  1)   0.656 us    |                  __module_address();
  1)   1.012 us    |                }
  1)   1.356 us    |              }
  1)   1.761 us    |            }

So just with a reasonably sized backtrace easily 10-20us can be spent
on just checking the frame pointer IPs.

The main cost is simply walking this long list of modules and checking it.

On 64bit kernels we can do a short cut. All modules are in a special reserved
virtual address space area. So only check for that range, which is much cheaper.

This has the (small) potential to get a false positive on a pointer to a
data segment in a module.  However since we also use the frame pointer
chain as initial sanity check I think the danger of this is very low.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 arch/x86/kernel/dumpstack.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index b74ebc7..b7cbae3 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -130,8 +130,20 @@ print_context_stack_bp(struct thread_info *tinfo,
 	while (valid_stack_ptr(tinfo, ret_addr, sizeof(*ret_addr), end)) {
 		unsigned long addr = *ret_addr;
 
+#ifdef CONFIG_64BIT
+		/*
+		 * On 64 bit the modules are in a special reserved
+		 * area, so we can just check the range.
+		 * It is not as exact as a full lookup, but together
+		 * with the frame pointer it is good enough.
+		 */
+		if (!core_kernel_text(addr) &&
+		    !(addr >= MODULES_VADDR && addr < MODULES_END))
+			break;
+#else
 		if (!__kernel_text_address(addr))
 			break;
+#endif
 
 		ops->address(data, addr, 1);
 		frame = frame->next_frame;
-- 
1.9.3


  reply	other threads:[~2014-09-26 23:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-26 23:31 Optimize backtrace code for perf PMI handler Andi Kleen
2014-09-26 23:31 ` Andi Kleen [this message]
2014-09-29 11:42   ` [PATCH 1/2] Use faster check for modules in backtrace on 64bit Peter Zijlstra
2014-09-29 15:21     ` Andi Kleen
2014-09-29 20:30       ` Andi Kleen
2014-09-30  8:58         ` Peter Zijlstra
2014-09-30 20:10           ` Andi Kleen
2014-10-02 10:57             ` Peter Zijlstra
2014-10-03 23:20               ` Andi Kleen
2014-09-26 23:31 ` [PATCH 2/2] x86: Only do a single page fault for copy_from_user_nmi Andi Kleen
2014-09-29 11:56   ` Peter Zijlstra
2014-09-29 15:26     ` Andi Kleen
2014-10-03  4:53       ` Ingo Molnar
2014-10-03 23:25         ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1411774277-4198-2-git-send-email-andi@firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=ak@linux.intel.com \
    --cc=dave@sr71.net \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome