Prev: [PATCH 2/5] cpumask: make task_struct.cpus_allowed a cpumask_var_t
Next: reply ASAP!!!
From: Peter Zijlstra on 4 Aug 2010 07:00
On Sun, 2010-07-18 at 21:06 +0100, Matt Fleming wrote:
> On Sat, 26 Jun 2010 16:14:46 +0100, Matt Fleming <matt(a)console-pimps.org> wrote:
> > On Fri, 25 Jun 2010 16:48:05 +0200, Peter Zijlstra <peterz(a)infradead.org> wrote:
> > >
> > > Ah, yes, it would be nice for SH (which doesn't have a PMI) to couple a
> > > software timer with their hardware counter to get samples.
> > >
> > > Never got around to actually implementing that though, maybe Paul has a
> > > minion interested in making that work?
> >
> > I'll take a look at it.
>
> 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.

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matt Fleming on 4 Aug 2010 07:30
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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: [PATCH 2/5] cpumask: make task_struct.cpus_allowed a cpumask_var_t
Next: reply ASAP!!!