All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lin Ming <ming.m.lin@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	"eranian@gmail.com" <eranian@gmail.com>,
	"Gary.Mohr@Bull.com" <Gary.Mohr@bull.com>,
	Corey Ashford <cjashfor@linux.vnet.ibm.com>,
	"arjan@linux.intel.com" <arjan@linux.intel.com>,
	"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>,
	Paul Mackerras <paulus@samba.org>,
	"David S. Miller" <davem@davemloft.net>,
	Russell King <rmk+kernel@arm.linux.org.uk>,
	Paul Mundt <lethal@linux-sh.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 3/9] perf: export registerred pmus via sysfs
Date: Tue, 11 May 2010 10:43:52 +0800	[thread overview]
Message-ID: <1273545832.30322.4.camel@minggr.sh.intel.com> (raw)
In-Reply-To: <1273490824.5605.3379.camel@twins>

On Mon, 2010-05-10 at 19:27 +0800, Peter Zijlstra wrote:
> On Mon, 2010-05-10 at 18:26 +0800, Lin Ming wrote:
> 
> > > No, I'm assuming there is only 1 PMU per CPU. Corey is the expert on
> > > crazy hardware though, but I think the sanest way is to extend the CPU
> > > topology if there's more structure to it.
> > 
> > But our goal is to support multiple pmus, don't we need to assume there
> > are more than 1 PMU per CPU?
> 
> No, because as I said, then its ambiguous what pmu you want. If you have
> that, you need to extend your topology information.
> 
> Anyway, I talked with Ingo on this and he'd like to see this somewhat
> extended.
> 
> Instead of a pmu_id field, which we pass into a new
> perf_event_attr::pmu_id field, how about creating an event_source sysfs
> class. Then each class can have an event_source_id and a hierarchy of
> 'generic' events.
> 
> We'd start using the PERF_TYPE_ space for this and express the
> PERF_COUNT_ space in the event attributes found inside that class.
> 
> That way we can include all the existing event enumerations into this as
> well.
> 
> This way we can create:
> 
> /sys/devices/system/cpu/cpuN/cpu_hardware_events 
>                              cpu_hardware_events/event_source_id
>                              cpu_hardware_events/cpu_cycles
>                              cpu_hardware_events/instructions
>                                                 /...
> 
> /sys/devices/system/cpu/cpuN/cpu_raw_events
>                              cpu_raw_events/event_source_id
> 
> 
> These would match the current PERF_TYPE_* values for compatibility
> 
> For new PMUs we can start a dynamic range of PERF_TYPE_ (say at 64k but
> that's not ABI and can be changed at any time, we've got u32 to play
> with).
> 
> For uncore this would result in:
> 
> /sys/devices/system/node/nodeN/node_raw_events
>                                node_raw_events/event_source_id
> 
> and maybe:
> 
> /sys/devices/system/node/nodeN/node_events
>                                node_events/event_source_id
>                                node_events/local_misses
>                                           /local_hits
>                                           /remote_misses
>                                           /remote_hits
>                                           /...
> 
> 
> The software events and tracepoints and kprobes stuff we could hang off
> of /sys/kernel/ or something
> 
> So your registration would indeed look like something:
> 
>  perf_event_register_pmu(struct pmu *pmu, int type),
> 
> where type would normally be -1 (dynamic) but would be PERF_TYPE_ for
> those already laid down in ABI.
> 
> This approach will also give us a good overview
> in /sys/class/event_source/, which will be a flat listing of all
> existing event sources.
> 
> Does this make sense?

Thanks for the idea.

Give me some time to get a clear understanding of the ideas from you and
others.

And then I'll work out a patch as soon as possible.

Lin Ming


  parent reply	other threads:[~2010-05-11  2:44 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-10  9:27 [RFC][PATCH 3/9] perf: export registerred pmus via sysfs Lin Ming
2010-05-10  9:40 ` Peter Zijlstra
2010-05-10 10:11   ` Lin Ming
2010-05-10 10:18     ` Peter Zijlstra
2010-05-10 10:26       ` Lin Ming
2010-05-10 10:35         ` Paul Mundt
2010-05-10 10:58           ` Lin Ming
2010-05-10 11:04             ` Peter Zijlstra
2010-05-10 11:11               ` Lin Ming
2010-05-10 11:18                 ` Lin Ming
2010-05-10 11:27         ` Peter Zijlstra
2010-05-10 11:36           ` Peter Zijlstra
2010-05-10 11:48             ` Ingo Molnar
2010-05-10 11:39           ` Russell King
2010-05-10 11:42           ` Peter Zijlstra
2010-05-10 20:25             ` Will Deacon
2010-05-11  6:34               ` Peter Zijlstra
2010-05-10 11:43           ` Ingo Molnar
2010-05-10 11:49             ` Peter Zijlstra
2010-05-10 11:53               ` Ingo Molnar
2010-05-10 23:13                 ` Corey Ashford
2010-05-11  6:46                   ` Peter Zijlstra
2010-05-11  7:21                     ` Ingo Molnar
2010-05-11  8:20                       ` Lin Ming
2010-05-11  8:50                         ` Peter Zijlstra
2010-05-11  9:03                           ` Lin Ming
2010-05-11  9:05                             ` Lin Ming
2010-05-11  9:12                             ` Peter Zijlstra
2010-05-11  9:18                               ` Ingo Molnar
2010-05-11  9:24                                 ` Peter Zijlstra
2010-05-11  9:31                                   ` Ingo Molnar
2010-05-11 10:28                                     ` Lin Ming
2010-05-13  8:28                                 ` Lin Ming
2010-05-13  8:38                                   ` Ingo Molnar
2010-05-13  9:22                                     ` Lin Ming
2010-05-11  9:40                               ` Lin Ming
2010-05-11  9:48                                 ` Peter Zijlstra
2010-05-11  9:53                                   ` Lin Ming
2010-05-11 15:17                                   ` Greg KH
2010-05-12  5:51                                   ` Paul Mundt
2010-05-12  8:37                                     ` Peter Zijlstra
2010-05-14  7:04                                       ` Paul Mundt
2010-05-11 10:09                   ` stephane eranian
2010-05-11 14:15             ` Borislav Petkov
2010-05-11 14:25               ` Peter Zijlstra
2010-05-11 15:37                 ` Borislav Petkov
2010-05-11 15:46                   ` Peter Zijlstra
2010-05-10 23:54           ` Corey Ashford
2010-05-11  6:50             ` Peter Zijlstra
2010-05-11  2:43           ` Lin Ming [this message]
2010-05-11  6:35             ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1273545832.30322.4.camel@minggr.sh.intel.com \
    --to=ming.m.lin@intel.com \
    --cc=Gary.Mohr@bull.com \
    --cc=arjan@linux.intel.com \
    --cc=cjashfor@linux.vnet.ibm.com \
    --cc=davem@davemloft.net \
    --cc=eranian@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=yanmin_zhang@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.