Re: [RFC] perf_events: support for uncore a.k.a. nest units

[Lin Ming <ming.m.lin@intel.com>]

On Fri, 2010-04-16 at 21:24 +0800, Peter Zijlstra wrote:
> On Thu, 2010-04-15 at 14:16 -0700, Gary.Mohr@Bull.com wrote:
> > > On Tue, 2010-03-30 at 09:49 -0700, Corey Ashford wrote:
> > >
> > > Right, I've got some definite ideas on how to go here, just need some
> > > time to implement them.
> > >
> > > The first thing that needs to be done is get rid of all the __weak
> > > functions (with exception of perf_callchain*, since that really is arch
> > > specific).
> > >
> > > For hw_perf_event_init() we need to create a pmu registration facility
> > > and lookup a pmu_id, either passed as an actual id found in sysfs or an
> > > open file handle from sysfs (the cpu pmu would be pmu_id 0 for backwards
> > > compat).
> > >
> > > hw_perf_disable/enable() would become struct pmu functions and
> > > perf_disable/enable need to become per-pmu, most functions operate on a
> > > specific event, for those we know the pmu and hence can call the per-pmu
> > > version. (XXX find those sites where this is not true).
> > >
> > > Then we can move to context, yes I think we want new context for new
> > > PMUs, otherwise we get very funny RR interleaving problems. My idea was
> > > to move find_get_context() into struct pmu as well, this allows you to
> > > have per-pmu contexts. Initially I'd not allow per-pmu-per-task contexts
> > > because then things like perf_event_task_sched_out() would get rather
> > > complex.
> > >
> > > For RR we can move away from perf_event_task_tick and let the pmu
> > > install a (hr)timer for this on their own.
> > >
> > > I've been planning to implement this for more than a week now, its just
> > > that other stuff keeps getting in the way.
> > >
> > 
> > Hi Peter,
> > 
> > My name is Gary Mohr and I work for Bull Information Systems.  I have been
> > following your discussions with Corey (and others) about how to implement
> > support for nest PMU's in the linux kernel.
> > 
> > My company feels that support for Intel Nehalem uncore events is very
> > important to our customers.  Has the "other stuff" mentioned above quited down to
> > allow you to get started on building support for these features ?? 
> 
> Sadly no.
> 
> >  If development
> > is actually in progress, would you be willing to make a guess as to which
> > version of the kernel may offer the new capabilities ??
> > 
> > As I said we are interested so if there is any way we can assist you,
> > please let us know.  We would be happy to take experimental patch sets and
> > validate, test, and debug any problems we encounter if that would help your
> > development.
> 
> Supply patches to make the above happen ;-)

Hi, 

I have been also looking at this for some time.
I'll send a draft patch later this week to support multiple hw pmus.

Lin Ming