From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Andi Kleen <andi@firstfloor.org>
Cc: acme@ghostprotocols.net, linux-kernel@vger.kernel.org,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 3/4] perf_events: Support a lock_parent event flag
Date: Tue, 20 Sep 2011 11:16:00 +0200 [thread overview]
Message-ID: <1316510160.11841.12.camel@twins> (raw)
In-Reply-To: <1316127412-1912-3-git-send-email-andi@firstfloor.org>
On Thu, 2011-09-15 at 15:56 -0700, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> Add a new lock_parent flag to the event attribute. When it is set
> account spinlocks to the parent. This is similar to how oprofile
> behaves on x86. This just reuses the oprofile code for this.
>
> The main advantage is that it allows to make more sense of locking
> problems without requiring full callgraphs.
>
> Right now only implemented on x86.
>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---
> arch/x86/kernel/cpu/perf_event.c | 3 +++
> include/linux/perf_event.h | 3 ++-
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
> index 373a614..f2caa6e 100644
> --- a/arch/x86/kernel/cpu/perf_event.c
> +++ b/arch/x86/kernel/cpu/perf_event.c
> @@ -1933,6 +1933,9 @@ unsigned long perf_instruction_pointer(struct pt_regs *regs,
> else
> ip = instruction_pointer(regs);
>
> + if (event->attr.lock_parent)
> + ip = __profile_pc(ip, regs);
> +
> return ip;
> }
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index f8b93ec..51da085 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -219,8 +219,9 @@ struct perf_event_attr {
> precise_ip : 2, /* skid constraint */
> mmap_data : 1, /* non-exec mmap data */
> sample_id_all : 1, /* sample_type all events */
> + lock_parent : 1, /* count locks in parent */
>
This all just sucks horridly. So this name tells us we need inherited
counters so that whenever we encounter a lock it will be accounted in
the parent process, or whatever -- which doesn't make any sense.
Furthermore, the sole reason you want this is because you don't want
callchains, supposedly because they're too expensive, but then you don't
say that.
How about you provide means of limiting the callchain depth, and then
frob the in_lock_function() and unwind 1 crap in userspace?
next prev parent reply other threads:[~2011-09-20 9:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 22:56 [PATCH 1/4] ptrace: Add variant of profile_pc for passing in pc Andi Kleen
2011-09-15 22:56 ` [PATCH 2/4] perf_events: Pass the event to perf_instruction_pointer Andi Kleen
2011-09-15 23:16 ` Thomas Gleixner
2011-09-15 22:56 ` [PATCH 3/4] perf_events: Support a lock_parent event flag Andi Kleen
2011-09-20 9:16 ` Peter Zijlstra [this message]
2011-09-20 17:51 ` Andi Kleen
2011-09-15 22:56 ` [PATCH 4/4] perf tools: Add -l flag to top/record to account to parent 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=1316510160.11841.12.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=linux-kernel@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
Powered by JetHome