Re: disabling group leader perf_event
From: Avi Kivity
Date: Mon Sep 06 2010 - 07:59:15 EST
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/