From: Frederic Weisbecker <fweisbec@gmail.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Prasad <prasad@linux.vnet.ibm.com>,
Alan Stern <stern@rowland.harvard.edu>,
Peter Zijlstra <peterz@infradead.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
Jiri Slaby <jirislaby@gmail.com>, Li Zefan <lizf@cn.fujitsu.com>,
Avi Kivity <avi@redhat.com>, Mike Galbraith <efault@gmx.de>,
Masami Hiramatsu <mhiramat@redhat.com>
Subject: Re: [PATCH 2/5] perf_counter: Export various perf helpers for external users
Date: Thu, 10 Sep 2009 20:43:49 +0200 [thread overview]
Message-ID: <20090910184345.GB6421@nowhere> (raw)
In-Reply-To: <19112.58078.764004.864248@cargo.ozlabs.ibm.com>
On Thu, Sep 10, 2009 at 09:28:30PM +1000, Paul Mackerras wrote:
> Frederic Weisbecker writes:
>
> > Export various perf helpers that initialize, destroy, attach and detach
> > a perf counter for future external users like the hardware breakpoint api.
>
> You are exporting things that are quite deep into the guts of the
> perf_counter code, which makes me think that what you're exporting
> isn't the right abstraction. At the least, your commit message needs
> to talk about what these external users want to do and why they need
> to reach so deeply into the perf_counter internals.
Yeah those are quite deep in perf internals but I don't have
much the choice. I can't (I shouldn't) call sys_perf_open()
directly so I need to do about the same things that are done
from this syscall, without the file handling.
But I agree this needs more comments and explanations in the
changelog. I'll add these for the v2.
> > The allocation and initialization of a perf counter have been split up
> > so that an external user can first allocate and then prefill the
> > counter before initialize it properly.
>
> Once again, this sounds like the wrong abstraction to me. Can you
> explain why first allocating and then prefilling it before
> initializing it properly is necessary or desirable?
>
> Paul.
You're right this is wrong. And this was even meant to be
reverted in further incremental patches.
The reason is that struct perf_counter embeds a struct hw_breakpoint.
And I need it to be inserted right between the counter allocation
and its initialization for it to take effect while calling
bp_perf_counter_init()
Ingo noticed the 1:1 relationship between struct hw_breakpoint
and struct perf_counter and suggested to remove the former and create
core breakpoint field inside perf attributes.
I like the idea, that would shrink the code and also bring a
unified way to set the breakpoints parameters in the counter
(for both syscall and in-kernel uses).
And then we won't need anymore this alloc/init split, which means
this change would have been reverted in further patches.
But I guess I should do that right in the beginning (in this
patchset) instead of later. So I will do that in the v2.
Thanks.
next prev parent reply other threads:[~2009-09-10 18:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-10 8:29 [RFC GIT PULL] hw-breakpoints: Rewrite on top of perf counters Frederic Weisbecker
2009-09-10 8:29 ` [PATCH 1/5] perf_counter: Add open/close pmu callbacks Frederic Weisbecker
2009-09-10 11:22 ` Paul Mackerras
2009-09-10 18:46 ` Frederic Weisbecker
2009-09-10 8:29 ` [PATCH 2/5] perf_counter: Export various perf helpers for external users Frederic Weisbecker
2009-09-10 11:28 ` Paul Mackerras
2009-09-10 18:43 ` Frederic Weisbecker [this message]
2009-09-10 8:29 ` [PATCH 3/5] hw-breakpoints: Rewrite the hw-breakpoints layer on top of perf counters Frederic Weisbecker
2009-09-10 14:25 ` K.Prasad
2009-09-10 18:53 ` Frederic Weisbecker
2009-09-10 21:18 ` Peter Zijlstra
2009-09-14 21:18 ` Frederic Weisbecker
2009-09-14 17:17 ` K.Prasad
2009-09-14 21:33 ` Frederic Weisbecker
2009-09-11 22:09 ` Jan Kiszka
2009-09-14 3:41 ` Frederic Weisbecker
2009-09-14 6:24 ` Jan Kiszka
2009-09-14 18:01 ` Frederic Weisbecker
2009-09-14 17:28 ` K.Prasad
2009-09-14 21:36 ` Frederic Weisbecker
2009-09-10 8:29 ` [PATCH 4/5] hw-breakpoints: Arbitrate access to pmu following registers constraints Frederic Weisbecker
2009-09-10 14:41 ` Daniel Walker
2009-09-10 14:57 ` Peter Zijlstra
2009-09-10 14:59 ` Daniel Walker
2009-09-10 15:02 ` Steven Rostedt
2009-09-10 18:53 ` Frederic Weisbecker
2009-09-10 8:29 ` [PATCH 5/5] ksym_tracer: Remove KSYM_SELFTEST_ENTRY Frederic Weisbecker
2009-09-10 10:09 ` [RFC GIT PULL] hw-breakpoints: Rewrite on top of perf counters Paul Mackerras
2009-09-10 17:23 ` Ingo Molnar
2009-09-10 18:24 ` Frederic Weisbecker
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=20090910184345.GB6421@nowhere \
--to=fweisbec@gmail.com \
--cc=acme@redhat.com \
--cc=avi@redhat.com \
--cc=efault@gmx.de \
--cc=jan.kiszka@siemens.com \
--cc=jirislaby@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=prasad@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
--cc=stern@rowland.harvard.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.