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]
Message-ID: <20120109152855.GA1597@m.brq.redhat.com>
Date:	Mon, 9 Jan 2012 16:28:55 +0100
From:	Jiri Olsa <jolsa@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	acme@...hat.com, mingo@...e.hu, paulus@...ba.org,
	cjashfor@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org
Subject: Re: new syntax for perf event

On Thu, Jan 05, 2012 at 03:10:56PM +0100, Peter Zijlstra wrote:
> On Wed, 2011-12-21 at 17:16 +0100, Jiri Olsa wrote:
> > grammar
> 
> yacc/bison notation it seems.. lemme get the rules for that.
> 
> > -------
> > events:
> >                 event_mod ',' event_mod | event_mod
> 
> events = event_mod, {',' , event_mod};
> 
> would be the EBNF variant for allowing inf repetition, not sure how to
> express that, it seems to want a recursive rule which I'm not sure I
> see. The way I read your thing it only allows 1 or 2 events.

aargh, sure we want more than 2 events ;)
should have been something like:

events: events ',' event_mod | event_mod


> 
> > 
> > event_mod:
> >                 event | event ':' modifier
> 
> 
> event_mod = event, [':' , modifier];
> 
> Would be the EBNF thing, and I think your rule does indeed match that.
> 
> > event:
> >                 event_symbol |
> >                 event_cache |
> >                 'cpu' '/' event_cpu |
> >                 'tracepoint' '/' event_tracepoint
> >                 'breakpoint' '/' event_breakpoint
> 
> I think I'd like to see something like:
> 
> event   = pmu, '/', event_config 
> 	| event_symbol | event_cache;
> 
> pmu = ? ls /sys/bus/event_source/devices ?;

ok


> (* maybe add some aliasses like you suggest *)
> 
> event_config = (event_predef | event_term), {',', event_term};
> 
> event_predef = ? special name -> raw mapping read from somewhere ?;
> 
> event_term = event_sym, '=', value;
> 
> event_sym = "config" | "config1" | "config2"
> 	  | ? contents of /sys/bus/event_source/devices/$pmu/format ?;

anyone working on the 'format' stuff? ;) I guess thats the place,
where we can stay with hardcoded config[12] so far.. right?


> 
> value = integer | hexint;
> 
> 
> > event_symbol:
> >                 cpu-cycles|cycles
> >                 stalled-cycles-frontend|idle-cycles-frontend
> >                 stalled-cycles-backend|idle-cycles-backend
> >                 instructions
> >                 cache-references
> >                 cache-misses
> >                 branch-instructions|branches
> >                 branch-misses
> >                 bus-cycles
> >                 cpu-clock
> >                 task-clock
> >                 page-faults|faults
> >                 minor-faults
> >                 major-faults
> >                 context-switches|cs
> >                 cpu-migrations|migrations
> >                 alignment-faults
> >                 emulation-faults
> > 
> > event_cache:
> >                 cache_type
> >                 cache_type '-' cache_result_op
> >                 cache_type '-' cache_result_op '-' cache_result_op
> 
> I'd write that as:
> 
> event_cache = cache_type, '-', cache_mod, ['-', cache_xs];
> 
> cache_type = cache_l1d | cache_l1i | cache_llc 
> 	   | cache_dtlb | cache_itlb
> 	   | cache_branch | cache_node;
> 
> cache_mod = cache_load | cache_store | cache_prefetch;
> 
> cache_xs = cache_accesses | cache_misses;
> 
> cache_l1d = "L1-dcache" | ... ;

ok


> 
> etc..
> 
> 
> > event_cpu:
> >                 'raw'    ',' event_cpu_def
> >                 'hw'     ',' event_cpu_def
> >                 'cache'  ',' event_cpu_def
> 
> I think these are superfluous and we could deduce them from the actual
> event_term's used. Something using "config" will be a raw event etc..

ok


> 
> > 
> > event_cpu_def:
> >                 event_cpu_ass ',' event_cpu_ass |
> >                 event_cpu_ass
> > 
> > event_cpu_ass:
> >                 event_cpu_elem '=' value
> 
> Hehehe, you said 'ass', hehe.
eh.. you're seeing things ;) just best fitting abbrev..


> 
> 
> > event_tracepoint:
> >                 system ':' tracepoint
> > 
> > event_breakpoint:
> >                 addr ':' type
> 
> Right, something like that.
> 
> > 
> > modifier:
> >                 [ukhp]{1,4} 
> 
> I think you need at least 5, or you can write it like:
> 
> modifier = ['u'], ['k'], ['h'], [3*'p'];
> 
> Also, I think we grew a few more modifiers with some of the perf kvm
> guest muck.

yep, I'll update it..
I'll prepare another patch version including above changes

thanks,
jirka
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ