Messages in this thread | | | Date | Fri, 29 Mar 2013 15:25:04 +0100 | From | Borislav Petkov <> | Subject | Re: [RFC PATCH 0/3] Perf persistent events |
| |
On Thu, Mar 28, 2013 at 04:52:29PM +0100, Robert Richter wrote: > An option would be to attach the persistent events to a hosting pmu > (e.g. 'ras' in this case) and provide the events via sysfs as already > done by other pmus: > > /sys/bus/event_source/devices/ras/events/ > /sys/bus/event_source/devices/ras/events/mce_record > ... > > perf tools work then out-the-box with -e ras/mce_record/. > > The event is selected by the 'ras' pmu and then routed to the original > pmu that might be e.g. 'tracepoint'. So we attach each persistent > event to a 'virtual' pmu which does the grouping in the perf sysfs and > the forwarding to its actual pmu.
As I told you already in IRC, persistent events should be completely generic and not only related to ras. IOW, *all* possible events we have now should be also be able to be created as persistent. What I mean is:
perf -e kvm:kvm_page_fault:P ... <target_task>
should mean that I want to collect *all* kvm page faulting events during the system's lifetime not only during target_task executes.
And the "P" I've chosen arbitrary to mean persistent.
Which raises a couple more questions like what would happen with those events once the perf tool call above exits. Obviously, the event should stay enabled. Also, a subsequent call of this would mean "do not open another persistent event of this type but give the persistent file descriptor instead" and so on and so on.
Now, this probably can be solved with a virtual 'persistent' pmu which 'hosts' all persistent events. The question is, do we want to do it this way?
What do the others think?
P.S. Btw, some of the concerns you've raised in your other mail have been already addressed here:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git persistent5
and I'll look at the remaining ones when I get back.
Thanks.
| |