Re: [RFC PATCH 0/3] perf: show package power consumption in perf

From: Matt Fleming
Date: Thu Aug 19 2010 - 04:32:23 EST


On Thu, Aug 19, 2010 at 04:31:54PM +0800, Zhang Rui wrote:
> On Thu, 2010-08-19 at 15:54 +0800, Matt Fleming wrote:
> > On Thu, Aug 19, 2010 at 11:28:17AM +0800, Lin Ming wrote:
> > > On Wed, 2010-08-18 at 20:41 +0800, Matt Fleming wrote:
> > > >
> > > > I had a quick look over the patches and Peter is right - the group
> > > > events stuff would probably fit quite well here. Unfortunately, due to
> > > > holidays and things, I haven't been able to get them finished
> > > > yet. I'll get on that ASAP.
> > >
> > > Hi, Matt
> > >
> > > What's the "group events stuff"?
> > > Is there some discussion on LKML or elsewhere I can have a look at?
> > >
> > > Thanks,
> > > Lin Ming
> >
> > The relevant information can be found here in this thread,
> > http://lkml.org/lkml/2010/8/4/174. I'm working on some patches for
> > this but they're not finished yet. I can probably get something to
> > show by next week.
> >
> > The discussion started because the performance counters on SH do not
> > generate an interrupt on overflow, so we need to periodically sample
> > them. Am I correct in thinking that the energy counters also do not
> > generate an interrupt on overflow and that's why you wrote the event
> > as a software event?
>
> right.
>
> BTW, I'm not quite familiar with perf tool, and now I'm wondering if the
> periodically sample is needed.
> because IMO, .start is invoked every time the process is scheduled in,
> and .stop is invoked when it's scheduled out. It seems that we just need
> to read the energy consumed in .start and .stop, and update the counter
> in .stop, right?

How big is the hardware counter? The problem comes when the process is
scheduled in and runs for a long time, e.g. so long that the energy
hardware counter wraps. This is why it's necessary to periodically
sample the counter.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/