mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joshua Pincus <joshua.pincus@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	"K.Prasad" <prasad@linux.vnet.ibm.com>,
	paulus@samba.org, acme@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: HW breakpoints perf_events request
Date: Thu, 14 Jan 2010 10:02:44 -0800	[thread overview]
Message-ID: <bc915a051001141002h3ed92e75o95318fa2f8a20d21@mail.gmail.com> (raw)
In-Reply-To: <1263458665.4244.256.camel@laptop>

Hi Peter,

On Thu, Jan 14, 2010 at 12:44 AM, Peter Zijlstra
> We have fnctl() managing signal support, but that will only interrupt
> the observing thread, not the threads being observed (unless they are
> one and the same -- but using inheritance precludes that from being
> true).
>
> I'm not sure I'm willing to go in this direction with perf, the idea is
> to have a minimum impact on the observed threads, explicitly sending
> them signals and disturbing their execution goes against this.

I understand your qualms.

I'm not asking for this feature to be implemented as the
default.  I'm asking that it be an option for someone like me to use.
We have a very strong
and compelling reason for doing what I've requested
vis a vis observed threads.  I am sure we can come up
with other compelling reasons for doing this, not the least
of which is that this functionality has been provided
in Microsoft Windows for a decade or more and has
proven immensely useful.

For instance, one could use this as a realtime watchdog
without requiring extra observing threads to do the
signal processing work.  Or having observed threads
use the signal handler to tally up events.

Without the ability for observed threads to be interrupted
in this way when they hit breakpoints, the new
perf_event work is not going to be useful to us in its
current form.

Thanks,
JP


>
>

  reply	other threads:[~2010-01-14 18:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-14  1:45 Joshua Pincus
2010-01-14  2:15 ` Andi Kleen
2010-01-14  2:21   ` Joshua Pincus
2010-01-14  9:23     ` Andi Kleen
2010-01-14 18:03       ` Joshua Pincus
2010-01-18 11:04         ` Frederic Weisbecker
2010-01-18 11:35           ` Andi Kleen
2010-01-19 14:40             ` Frederic Weisbecker
2010-01-18 16:33           ` Frank Ch. Eigler
2010-01-19 14:50             ` Frederic Weisbecker
2010-01-19 15:12               ` Frank Ch. Eigler
2010-01-19 16:21                 ` Frederic Weisbecker
2010-01-19 16:26                   ` Peter Zijlstra
2010-01-19 17:44                   ` Frank Ch. Eigler
2010-01-14  5:10 ` Frederic Weisbecker
2010-01-14  8:44 ` Peter Zijlstra
2010-01-14 18:02   ` Joshua Pincus [this message]
2010-01-18 17:45 ` K.Prasad
2010-01-19 14:53   ` 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=bc915a051001141002h3ed92e75o95318fa2f8a20d21@mail.gmail.com \
    --to=joshua.pincus@gmail.com \
    --cc=acme@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®