All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: eranian@google.com
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, paulus@samba.org,
	davem@davemloft.net, fweisbec@gmail.com, robert.richter@amd.com,
	perfmon2-devel@lists.sf.net, eranian@gmail.com
Subject: Re: [RFC][PATCH] perf_events: added new start/stop PMU callbacks
Date: Mon, 08 Feb 2010 17:30:11 +0100	[thread overview]
Message-ID: <1265646612.11509.13.camel@laptop> (raw)
In-Reply-To: <4b703875.0a04d00a.7896.ffffb824@mx.google.com>

On Mon, 2010-02-08 at 17:06 +0200, Stephane Eranian wrote:
> 	In certain situations, the kernel may need to stop and start the
> 	same event rapidly. The current PMU callbacks do not distinguish
> 	between stop and release  (i.e., stop + free the resource). Thus,
> 	a counter may be released, then it will be immediately re-acquired.
> 	Event scheduling will again take place with no guarantee to assign
> 	the same counter. On some processors, this may event yield to failure
> 	to assign the event back due to competion between cores.
> 
> 	This patch is adding a new pair of callback to stop and restart a
> 	counter without actually release the underlying counter resource.
> 	On stop, the counter is stopped, its values saved and that's it.
> 	On start, the value is reloaded and counter is restarted (on x86,
> 	actual restart is delayed until perf_enable()).
> 	
> 	Note this patch does not provide support for non-X86 PMU. This needs
> 	to be added.
> 
> 	Signed-off-by: Stephane Eranian <eranian@google.com>
> --

I think we can do this much easier by adding a list_head to
hw_perf_event and make event_list into a proper list, then we can remove
that funny loop on remove and instead move the event to a remove_list
when there's a put_event_constraint() method and iterate that list on
hw_perf_enable().

But before we do that, I think we need to look at the /* hardware */
part of struct hw_perf_event, and make that arch specific, we've been
growing that a lot lately and I don't think !x86 uses any of that.


  reply	other threads:[~2010-02-08 16:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-08 15:06 [RFC][PATCH] perf_events: added new start/stop PMU callbacks Stephane Eranian
2010-02-08 16:30 ` Peter Zijlstra [this message]
2010-02-08 17:21   ` Stephane Eranian
2010-02-09 13:00     ` Peter Zijlstra
2010-02-09 13:04     ` Peter Zijlstra
2010-02-26 10:25 ` [tip:perf/core] perf_events: Add " tip-bot for Stephane Eranian

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=1265646612.11509.13.camel@laptop \
    --to=peterz@infradead.org \
    --cc=davem@davemloft.net \
    --cc=eranian@gmail.com \
    --cc=eranian@google.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=perfmon2-devel@lists.sf.net \
    --cc=robert.richter@amd.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.