linux-kernel - Re: [RFC][PATCH v1 02/15] perf: export generic hardware events via sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 Jul 2010 10:18:23 +0800
From:	Lin Ming <ming.m.lin@...el.com>
To:	Robert Richter <robert.richter@....com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Johannes Berg <johannes@...solutions.net>,
	Peter Zijlstra <peterz@...radead.org>,
	Greg KH <greg@...ah.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	"eranian@...il.com" <eranian@...il.com>,
	"Gary.Mohr@...l.com" <Gary.Mohr@...l.com>,
	"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Paul Mackerras <paulus@...ba.org>,
	"David S. Miller" <davem@...emloft.net>,
	Russell King <rmk+kernel@....linux.org.uk>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Will Deacon <will.deacon@....com>,
	Maynard Johnson <mpjohn@...ibm.com>,
	Carl Love <carll@...ibm.com>,
	Kay Sievers <kay.sievers@...y.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [RFC][PATCH v1 02/15] perf: export generic hardware events via
 sysfs

On Fri, 2010-07-23 at 18:44 +0800, Robert Richter wrote:
> On 22.07.10 07:12:22, Lin Ming wrote:
> > Generic hardware events are exported under
> > /sys/devices/system/cpu/cpu0...N/events, for example
> > 
> > /sys/devices/system/cpu/cpu0/events
> > |-- L1-dcache-load-misses
> > |   |-- config
> > |   `-- type
> 
> The sysfs approach came up as a solution to connect to dynamically
> added pmus of various kind of hardware. The current mechanism using
> config/type style did not fit anymore because we would have to
> continuously extend the syscall i/f by new flags and attributes for
> every new event. So, the problem is not which config and type
> parameters to use for creating an event, we need a _different_ way for
> this.
> 
> The config and type value you expose to sysfs are only used for
> setting up the syscall. So, I want to bring up my idea again here that
> I posted some days ago to lkml, using a unique sysfs id to specify
> event classes.
> 
> Simply export an id (an u64), like:
> 
>  |-- L1-dcache-load-misses  ===> event name
>  |   `-- id                 ===> event id
> 
> ... and then extend the syscall to enable an event by its sysfs id:
> 
>             memset(&attr, 0, sizeof(attr));
>             attr.type        = PERF_TYPE_SYSFS;
>             attr.sysfs_id    = sysfs_id;
>             attr.sample_type = PERF_SAMPLE_CPU | PERF_SAMPLE_RAW;
>             attr.config      = config;
>             ...
> 
> The config value can then be (re-)used to setup this _specific_ event
> individually.
> 
> The kernel knows the id and is able to route the event request
> directly to that particular pmu, something like:
> 
> struct event_kobject {
>        struct kobject *kobj;
>        u64 id;
>        struct pmu *pmu;
>        struct event_kobject *next;
> };
> 
> struct event_kobject *eclass;
> 
> eclass = find_event_kobject(id);
> eclass->pmu->event_init(event);
> ...
> 
> This is very simple and flexible and solves the original problem too.

Yeah, this is flexible. I'll think about this closely.

Thanks,
Lin Ming

> 
> (reposting my previous mail:)
> 
> You still need knowledge of what the event is measuring and how it is
> set up or configured. Maybe the configuration may left blank if the
> event can be setup without it. But with this approach you can get file
> descriptors for every event a user may be interested in simply by
> looking into sysfs.
> 
> For example, I was thinking of perfctr events vs. ibs events. The cpu
> could setup something like:
> 
> /sys/devices/system/cpu/cpu0...cpuN/events/perfctr/id
> /sys/devices/system/cpu/cpu0...cpuN/events/ibs_op/id
> 
> Both events are setup with one 64 bit config value that is basically
> the event's configuration msr (x86 perfctr or AMD IBS). These are
> definded in the hardware specifications. Its formats differ. You could
> then open the event file descriptor using the sysfs id and use the
> config value to customize the event. You don't have a complicated
> setup or implementation to detect which kind of event you want to use
> as the id indicates the type of event.
> 
> Actually, we could setup e.g. also trace events with this mechanism.
> 
> -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/