Date:	Tue, 10 Mar 2009 10:44:57 +0100
From:	Robert Richter <robert.richter@....com>
To:	Paul Mackerras <paulus@...ba.org>
CC:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephane Eranian <eranian@...glemail.com>,
	Eric Dumazet <dada1@...mosbay.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Anvin <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"David S. Miller" <davem@...emloft.net>,
	Mike Galbraith <efault@....de>
Subject: Re: [announce] Performance Counters for Linux, v6

On 10.03.09 10:01:28, Paul Mackerras wrote:
> > Some points to mention here. This patch set actually introduces two
> > interfaces, a new user/kernel interface and an in-kernel api to access
> > performance counters. These are separate things and sometimes mixed
> > too much. There is a strong need for an in-kernel api. This is the
> 
> We have been concentrating more on the user/kernel API since that is
> the one that cannot be changed in an incompatible way once this stuff
> goes upstream.  The in-kernel API can be changed at any time and is
> still evolving.

I agree, it is much more easier to change the in-kernel i/f. I just
wanted to emphasize the importance of this i/f. Oprofile, Perfmon and
also LPC will exist in the future too and should share the same code
base. That's what I missed in the discussion until now.

> 
> > third implementation I am involved (oprofile, perfmon are the others)
> > and the things are always the same way. All these subsystems should be
> > merged to one in-kernel implemenation and share the same code. The
> > different user/kernel i/fs could then coexist and meet the users
> > different needs.
> 
> It would certainly be good to get oprofile to use the same low-level
> machinery as perf_counters.  I'm not sure what the fate of perfmon
> will be, but it seems unlikely it will go upstream in anything like
> its present form.

Right, as I sad above, all should share the same low-level code. And,
this code already exists. The question is more how to merge it and
bring the things together.

[...]

> > So, instead of making the list a public data structure, better pass
> > the type to an arch specific function, e.g.:
> > 
> > int arch_xxx_setup_event(int event_type);
> 
> That's exactly what we have, except that it's called
> hw_perf_counter_init and the event_type you have there is in the
> struct perf_counter that gets passed in.

Thanks for pointing this out, I was misinterpreting this as a general
hw initialization function, but instead a counter is allocated.

> 
> > If the type is not supported, an error could be returned. There is no
> > more impact. Even the binaries of the builds would be identically if
> > hw_event_types would be extended for a single different architecture.
> > 
> > The same applies also for counters and so on, better implement
> > functions.
> 
> All of that is already done; hw_perf_counter_init gets to interpret
> the counter->hw_event.type and counter->hw_event.raw fields and decide
> whether the event is supported, and return an error if not.  On x86 it
> looks like there is a further ops structure (struct pmc_x86_ops) which
> allows each x86-compatible cpu type to supply its own functions for
> doing the interpretation of counter->hw_event and other things.

Ok, maybe I mixed too much the architectural with the x86 model
specific implementation. My impression is that there is data in
generic structures what should be better private for the model or
architecture. However, I have to figure out the details here.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@....com

--
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