Messages in this thread | | | Date | Mon, 06 Sep 2010 14:58:51 +0300 | From | Avi Kivity <> | Subject | Re: disabling group leader perf_event |
| |
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?
Yes, exactly.
> 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
| |