All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: "K.Prasad" <prasad@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>, Paul Mundt <lethal@linux-sh.org>,
	linuxppc-dev@lists.ozlabs.org,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config
Date: Tue, 5 Jul 2011 15:49:25 +0200	[thread overview]
Message-ID: <20110705134920.GF5551@somewhere> (raw)
In-Reply-To: <20110704174416.GA2166@in.ibm.com>

On Mon, Jul 04, 2011 at 11:14:16PM +0530, K.Prasad wrote:
> On Mon, Jul 04, 2011 at 03:29:14PM +0200, Frederic Weisbecker wrote:
> > On Mon, Jul 04, 2011 at 06:57:46PM +0530, K.Prasad wrote:
> > > On Tue, May 24, 2011 at 11:52:23PM +0200, Frederic Weisbecker wrote:
> > > > Migrate conditional hw_breakpoint code compilation under
> > > > the new config to prepare for letting the user chose whether
> > > > or not to build this feature
> > > > 
> > > 
> > > Making the hardware breakpoint patches modular has always been a goal.
> > > I've looked at the PowerPC parts of the code and they look harmless.
> > > 
> > > Acked-by: K.Prasad <prasad@linux.vnet.ibm.com>
> > 
> > Great!
> > 
> > I'll push that soon, thanks guys for your acks!
> 
> Meanwhile, I was testing hardware breakpoints through perf and found
> that monitoring a given address fails when using 'perf record' (returns
> -ENOSPC) while 'perf stat' and watchpoint through gdb works fine (see
> logs below).
> 
> Has this behaviour been reported for other perf counters?

Nope I haven't anything like that. What I reported privately to you a
few ago was actually due to a mistake of mine. Otherwise I haven't seen
other problems.

-ENOSPC is likely related to the breakpoint slot reservation, in kernel/events/hw_breakpoint.c

  reply	other threads:[~2011-07-05 13:49 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-24 21:52 [PATCH v2] hw_breakpoint: Let the user choose not to build it (and perf too) Frederic Weisbecker
2011-05-24 21:52 ` Frederic Weisbecker
2011-05-24 21:52 ` [PATCH 1/6] hw_breakpoints: Split hardware breakpoints config Frederic Weisbecker
2011-05-24 21:52   ` Frederic Weisbecker
2011-05-24 21:52 ` [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config Frederic Weisbecker
2011-05-24 21:52   ` Frederic Weisbecker
2011-07-04 13:27   ` K.Prasad
2011-07-04 13:27     ` K.Prasad
2011-07-04 13:29     ` Frederic Weisbecker
2011-07-04 13:29       ` Frederic Weisbecker
2011-07-04 17:44       ` K.Prasad
2011-07-05 13:49         ` Frederic Weisbecker [this message]
2011-05-24 21:52 ` [PATCH 3/6] x86: Allow the user not to build hw_breakpoints Frederic Weisbecker
2011-05-24 21:52   ` Frederic Weisbecker
2011-05-24 21:52 ` [PATCH 4/6] hw_breakpoints: Breakpoints arch ability don't need perf events Frederic Weisbecker
2011-05-24 21:52   ` Frederic Weisbecker
2011-07-04 13:32   ` K.Prasad
2011-07-04 13:32     ` K.Prasad
2011-07-04 13:37     ` Frederic Weisbecker
2011-07-04 13:37       ` Frederic Weisbecker
2011-05-24 21:52 ` [PATCH 5/6] hw_breakpoints: Only force perf events if breakpoints are selected Frederic Weisbecker
2011-05-24 21:52   ` Frederic Weisbecker
2011-05-24 21:52 ` [PATCH 6/6] hw_breakpoints: Drop remaining misplaced dependency on perf Frederic Weisbecker
2011-05-24 21:52   ` Frederic Weisbecker
2011-05-25  2:27 ` [PATCH v2] hw_breakpoint: Let the user choose not to build it (and perf too) Paul Mundt
2011-05-25  2:27   ` Paul Mundt
  -- strict thread matches above, loose matches on Subject: below --
2011-07-14 15:03 [GIT PULL] hw_breakpoints updates Frederic Weisbecker
2011-07-14 15:03 ` [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config Frederic Weisbecker
2011-04-27 16:59 [PATCH 0/6] hw_breakpoint: Let the user choose not to build it (and perf too) Frederic Weisbecker
2011-04-27 16:59 ` [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config Frederic Weisbecker
2011-04-27 16:59   ` 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=20110705134920.GF5551@somewhere \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@elte.hu \
    --cc=prasad@linux.vnet.ibm.com \
    /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.