linux-kernel - Re: [PATCH 2/3] perf: Remove dead code in buildin-record.c

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: <20100804112517.GB25587@console-pimps.org>
Date:	Wed, 4 Aug 2010 12:25:17 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Gui Jianfeng <guijianfeng@...fujitsu.com>,
	Yanmin Zhang <yanmin_zhang@...ux.intel.com>, mingo@...e.hu,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH 2/3] perf: Remove dead code in buildin-record.c

On Wed, Aug 04, 2010 at 12:56:06PM +0200, Peter Zijlstra wrote:
> On Sun, 2010-07-18 at 21:06 +0100, Matt Fleming wrote:
> > 
> > How does the 'group_fd' parameter relate to the lack of PMI? Is the idea
> > to have one hrtimer that, when it fires, we sample all the counters? So
> > the first counter to be created is the group leader, which starts the
> > hrtimer, and all other counters are linked to this one? I had a go at
> > using a hrtimer per counter (minus any weighting of samples) and it
> > worked OK and seemed sensible given that we may want to sample counters
> > at different frequencies.
> > 
> > Is this what you had in mind with the 'group_fd' paramter, Peter? That
> > there'd be only one hrtimer?
> 
> Right. So sys_perf_event_open() creates a stand alone event, but if you
> supply the group_fd param it will attach the newly created one to the
> leader indicated by group_fd.
> 
> Groups have the properly that they will always be scheduled together,
> and read/sample can access/provide data of all of them.

Ah, I think I see. The benefit of scheduling these events together is
that we can then sample the counters at roughly the same time? As
opposed to the case where we have multiple hrtimers firing and the
counter values will be from vastly different times? Yeah, that makes
sense now.

> So you can have a sampling leader report the counts of its siblings.
> 
> You can make multiple groups, like {hrtimer, cycles} and {hrtimer,
> instructions} and {hrtimer, dcache-miss} and perf will schedule the
> stuff. If you'd try to do {hrtimer, cycles, insns, dcache-miss} but only
> have 2 hardware counters the group creation should fail because the
> implementation should dis-allow creating groups that cannot be
> scheduled 

Right, so the hrtimer is an event all by itself: the parent event?
--
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/