Re: disabling group leader perf_event
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On 09/06/2010 02:54 PM, Peter Zijlstra wrote:
Basically, to read() all events in one go. I have many of them. My current problem is that I have an event (kvm_exit) which I want to drill down by looking at a field (exit_reason). So I create lots of separate perf_events with a filter for each reason: kvm_exit(exit_reason==0), kvm_exit(exit_reason==1), etc. But filters are fairly slow (can have ~60 such events on AMD), so I want to make this drill-down optional.Yeah, filters suck.
Any idea why? I saw nothing obvious in the code, except that there is lots of it.
So what you're basically trying to do is create some histogram of exit_reason?
Being able to make histograms in-kernel has been on the todo list for a long while, its just that I never could come up with a sane interface.. :/
Interesting, I thought it was just me.One option is to keep the existing filter interface, but recognize those cases and optimize the implementation. Sort of like a compiler can optimize a large dense switch statement to a jump table.
Current plan is to have a group for the basic events and another group for the drilldown events (each per-cpu), and activate the drilldown group on user request. perf will be able to schedule both groups concurrently since they only contain tracepoints, yes?More or less, yeah (the scheduling of software and hardware events isn't properly separated atm -- am working on that). Software events have no scheduling constraints and should always get scheduled.
Great, thanks.(one other issue - right now I'm using cpu events. If I switch to task events, I lose events generated by workqueues, yes?)
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html