lkml.org 
[lkml]   [2012]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 5/9] perf: Add sysfs format attribute for pmu device
On Thu, Jan 26, 2012 at 05:26:49PM +0100, Peter Zijlstra wrote:
> On Mon, 2012-01-16 at 13:31 +0100, Jiri Olsa wrote:
> > Adding 'format' attribute for pmu device that contains
> > a syntax description on how to construct raw events.
> >
> > The event configuration is described in following
> > struct pefr_event_attr attributes:
> >
> > config
> > config1
> > config2
> >
> > Each line of the format file describes mapping of name
> > and bitfield definition within one of abve attributes.
> >
> > eg:
> > event config:0-7
> > umask config:8-15
> > usr config:16
> > os config:17
> > edge config:18
> > any config:21
> > inv config:23
> > cmask config:24-31
> >
> > Line syntax:
> > line: NAME config ':' bits
> > config: 'config' | 'config1' | 'config2"
> > bits: bits ',' bit_term | bit_term
> > bit_term: VALUE '-' VALUE | VALUE
> >
> > Adding event_format callback to the struct pmu, which provides
> > the format information. The pmu shall override this function
> > and provide its own specific format information.
> >
> > If not overloaded the default format information is used:
> >
> > config config:0-63
> > config1 config1:0-63
> > config2 config2:0-63
>
> Shouldn't config[012] be hard-coded like period? They are struct
> perf_event_attr members after all and it doesn't really make sense to
> have them dynamic if we're going to have to add them to all pmu/format
> things.

Well, let me clarify that config[12] and 'period' are different stuff.
Also I remember you asked me about the config terms namespace in some
other email and I forgot to answer :)


So, while period is event term that user can specify in the event config
section like:
cycles/period=100000/

the config[12] are values that are specified in the format definitions
as values that are changed by event terms.. like:
config1:1,6-10,44

Now for event terms.. whatever term name is specified in the pmu
format definition, it is considered as valid term, when the 'pmu' event
is configured.. eg events like:
cpu/krava=1/u

Apart from that we recognize the term 'period', which could be specified
only for symbolic events so far:
cycles/period=100000/

So there can't be name clash between 'period' term and the rest so far.
Once we would like to have say 'period' term inside 'pmu' events like:
cpu/krava=1,period=1000/u

we would need to consider some namespace rules or smth.


Now for config[12] formats.. they are parsed as simple strings and
'hardcoded' in function format_value. I think what you suggest is
to 'hardcode' them into the grammar... right?

So instead of using rule:
format_term: PP_NAME ':' bits

there'll be 3 rules like:

format_term: 'config':' bits
format_term: 'config1' ':' bits
format_term: 'config2' ':' bits

I dont have strong feelings one way or the other... but since we already
have the parser in place we could use it.. ehm :)


thanks,
jirka


\
 
 \ /
  Last update: 2012-01-27 13:35    [W:0.056 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site