[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87hbjwzhak.fsf@linux-g6p1.site>
Date: Sun, 18 Jul 2010 21:06:11 +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 Sat, 26 Jun 2010 16:14:46 +0100, Matt Fleming <matt@...sole-pimps.org> wrote:
> On Fri, 25 Jun 2010 16:48:05 +0200, Peter Zijlstra <peterz@...radead.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?
--
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