From: Frederic Weisbecker <fweisbec@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "K.Prasad" <prasad@linux.vnet.ibm.com>,
Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Alan Stern <stern@rowland.harvard.edu>,
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>, Paul Mackerras <paulus@samba.org>,
Mike Galbraith <efault@gmx.de>,
Masami Hiramatsu <mhiramat@redhat.com>
Subject: Re: [PATCH 3/5] hw-breakpoints: Rewrite the hw-breakpoints layer on top of perf counters
Date: Mon, 14 Sep 2009 23:18:24 +0200 [thread overview]
Message-ID: <20090914211822.GJ6045@nowhere> (raw)
In-Reply-To: <1252617481.7205.106.camel@laptop>
On Thu, Sep 10, 2009 at 11:18:01PM +0200, Peter Zijlstra wrote:
> On Thu, 2009-09-10 at 20:53 +0200, Frederic Weisbecker wrote:
> > On Thu, Sep 10, 2009 at 07:55:40PM +0530, K.Prasad wrote:
> > > On Thu, Sep 10, 2009 at 10:29:25AM +0200, Frederic Weisbecker wrote:
> > > > This patch rebase the implementation of the breakpoints API on top of
> > > > perf counters instances.
> > > >
> > > > The core breakpoint API has changed a bit:
> > > >
> > > > - register_kernel_hw_breakpoint() now takes a cpu as a parameter. For
> > > > now it doesn't support all cpu wide breakpoints but this may be
> > > > implemented soon.
> > >
> > > Is there a reason why perf doesn't support counters effective on all
> > > CPUs (and all processes)?
> > > Atleast, it is vital for debugging aspects of hw-breakpoints...say to
> > > answer "Who all did a 'write' on the kernel variable that turned corrupt", etc.
> > >
> > > The implementation to iteratively register a breakpoint on all CPUs would
> > > (as in trace_ksym.c) result in unclean semantics for the end user, when, a
> > > register_kernel_<> request fails on a given CPU and all previously
> > > registered breakpoints have to be reverted (but the user might have
> > > received a few breakpoint triggers by then as a result of the successful
> > > ones...i.e. register request fails, but still received 'some' output).
> >
> >
> > (Please shrink the end of the message if you don't answer in further parts.
> > I'm especially a bad example of what not to do :-)
Oh I was meaning "a good example"...
> >
> > Yeah it would be very convenient to have that. Is it possible considering
> > the current internal design of perf?
>
> Create the counters disabled? Maybe even group them to allow 'atomic'
> enable/disable.
I don't see why we need that.
The problem is that we need "all-cpu" counters.
May be we could pass a per cpu ptr to a
register_hardware_breakpoint_wide() that could do the trick by itself?
But that sounds too much workarounds while we would like only one
handler.
May be could we multiplex several per cpu counter into a single one?
next prev parent reply other threads:[~2009-09-14 21:18 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
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 [this message]
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=20090914211822.GJ6045@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.