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] [day] [month] [year] [list]
Message-ID: <20120718200619.GC5627@krava.redhat.com>
Date:	Wed, 18 Jul 2012 22:06:20 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	Ulrich Drepper <drepper@...il.com>
Cc:	Stephane Eranian <eranian@...gle.com>,
	Namhyung Kim <namhyung@...il.com>, acme@...hat.com,
	a.p.zijlstra@...llo.nl, mingo@...e.hu, paulus@...ba.org,
	cjashfor@...ux.vnet.ibm.com, fweisbec@...il.com,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	andi@...stfloor.org
Subject: Re: [PATCHv3 0/3] perf tool: Add new event group management

On Wed, Jul 18, 2012 at 08:34:10AM -0400, Ulrich Drepper wrote:
> On Wed, Jul 18, 2012 at 6:21 AM, Jiri Olsa <jolsa@...hat.com> wrote:
> > Well, I personally like the '{}' syntax more than '--group-events or --group-reads
> > option in front', it feels more user friendly.. anyway, we can easily have both ways.
> 
> I like the actual visual grouping better, too.
> 
> Also, it doesn't require us to define what
> 
>    -e E1,E2 --group-events -e E3,E4
> 
> means.  Does --group-events also apply to the first parameter?
> 
> 
> > As for the group attributes and group leader sampling, I don't mind omitting
> > them at this point and get back to that if we find it useful in future.
> 
> Just define the first event the leader.  What reason is there which
> prevents this?

yep, no problem.. first one is the leader

The group sampling is just another feature where you enable sampling
only for the leader and the rest of the events in the group are only
being read on leader's sample - they don't sample by themselves.

But this feature needs more testing, and event modifier syntax rethinking ;)
I'll send it later..

> I can only second what Andi wrote: just get it done quickly.  This is
> functionality that is desperately needed.

I have new patchset ready with group modifiers adding modifiers
to events in the group, like:

 {cycles:u,instructions:u}:p

adds 'p' to both events in the group
(in current patchset group modifier overwrites events modifiers)

if there's strong opinion/reasons against it, I can simply remove
it, but it looks helpful

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