[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130328155229.GP11449@rric.localhost>
Date: Thu, 28 Mar 2013 16:52:29 +0100
From: Robert Richter <rric@...nel.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Namhyung Kim <namhyung@...nel.org>, Borislav Petkov <bp@...en8.de>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Frederic Weisbecker <fweisbec@...il.com>,
Borislav Petkov <bp@...e.de>
Subject: Re: [RFC PATCH 0/3] Perf persistent events
On 18.03.13 09:46:38, Ingo Molnar wrote:
>
> * Namhyung Kim <namhyung@...nel.org> wrote:
>
> > So my question is how can an user know which persistent events are
> > available in her system?
>
> I think we need VFS enumeration for that: directories give a high level a
> structure (allowing things like per user contexts) while readdir will give
> list of specific persistent buffer contexts.
>
> Sensible naming convention would be needed to make things easy to discover
> and list - and for active buffers to not be forgotten about.
>
> cgroups or a new 'eventfs' filesystem would be an option.
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.
-Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists