Messages in this thread |  | | | Date | Mon, 8 Feb 2010 18:21:46 +0100 | | Subject | Re: [RFC][PATCH] perf_events: added new start/stop PMU callbacks | | From | Stephane Eranian <> |
| |
On Mon, Feb 8, 2010 at 5:30 PM, Peter Zijlstra <peterz@infradead.org> wrote: > 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().
Not sure why it's easier. It saves memory for sure, but that problem is independent of the issue I was trying to address.
> > 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. > It is clear it will need to grow much more to host non-counting features. I have played with that myself a few weeks back. So, yes the saved state needs to be arch specific. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |