From: Ingo Molnar <mingo@kernel.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
eranian@google.com, Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 1/2] Fix perf LBR filtering
Date: Wed, 1 May 2013 13:51:26 +0200 [thread overview]
Message-ID: <20130501115125.GA19497@gmail.com> (raw)
In-Reply-To: <20130426194633.GF16732@two.firstfloor.org>
* Andi Kleen <andi@firstfloor.org> wrote:
> >
> > OK, so how about we use something like:
> >
> > is_kernel_text() || is_module_text_address()
>
> is_module_text_address() has to walk all modules.
> A random system with a distro kernel I checked has 101 modules loaded.
I checked another random distro and it had 30 modules loaded.
> 16 * 101 = too much
>
> I don't think you want to spend that many cycles in the NMI
> handler for a dubious feature. Ok in theory you could
> add something with binary search, but that would be quite
> a bit of effort and it would be probably challenging
> to do that all NMI safe.
If anyone using LBR sees that overhead it can be improved. You or others
who care can improve it.
(Or if the hardware gets fully fixed, it can be removed for that
hardware.)
> Also it wouldn't work for all these new kernel JITs people are doing of
> course.
They'll miss the filtering, until they offer the proper
is_kernel_jit_text() primitive that is.
> Still think my patch is the best so far? (plus the missing root check)
Your patch simply disables the filtering for kernel addresses, it's the
worst of all options so far.
Anyway, what Peter asked for is a trivial change that solves the bug - are
you willing to respond to his review feedback and submit an updated
series?
Thanks,
Ingo
next prev parent reply other threads:[~2013-05-01 11:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-24 23:04 [PATCH 1/2] Fix perf LBR filtering Andi Kleen
2013-04-24 23:04 ` [PATCH 2/2] perf, x86: Don't allow unusual PEBS raw flags Andi Kleen
2013-04-29 22:16 ` Stephane Eranian
2013-04-29 22:34 ` Andi Kleen
2013-04-29 23:05 ` Stephane Eranian
2013-05-02 7:37 ` Peter Zijlstra
2013-05-06 17:44 ` Stephane Eranian
2013-05-06 18:52 ` Peter Zijlstra
2013-05-06 22:43 ` Stephane Eranian
2013-05-07 6:48 ` Ingo Molnar
2013-05-07 8:48 ` Peter Zijlstra
2013-05-07 11:04 ` Ingo Molnar
2013-05-07 8:43 ` Peter Zijlstra
2013-04-24 23:20 ` [PATCH 1/2] Fix perf LBR filtering Ben Hutchings
2013-04-24 23:24 ` Greg KH
2013-04-25 16:25 ` Peter Zijlstra
2013-04-25 16:41 ` Andi Kleen
2013-04-25 16:48 ` Peter Zijlstra
2013-04-25 17:00 ` Andi Kleen
2013-04-25 17:18 ` Peter Zijlstra
2013-04-25 17:42 ` Andi Kleen
2013-04-26 7:56 ` Peter Zijlstra
2013-04-26 19:46 ` Andi Kleen
2013-05-01 11:51 ` Ingo Molnar [this message]
2013-05-01 11:55 ` Ingo Molnar
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=20130501115125.GA19497@gmail.com \
--to=mingo@kernel.org \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=stable@vger.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