Messages in this thread |  | | | Subject | Re: [RFC][PATCH 00/11] perf pmu interface -v2 | | From | Peter Zijlstra <> | | Date | Thu, 01 Jul 2010 17:39:53 +0200 |
| |
On Thu, 2010-07-01 at 16:31 +0100, MattFleming wrote: > On Thu, Jul 01, 2010 at 05:02:35PM +0200, Peter Zijlstra wrote: > > > > Matt, you said it broke SH completely, but did you try perf stat? perf > > record is not supposed to work on SH due to the hardware not having an > > overflow interrupt. > > perf record does work to some degree. It definitely worked before > applying your changes but not after. I admit I haven't really read the > perf event code, but Paul will know.
Ok, let me look at that again.
> > Which made me think, what on SH guarantees we update the counter often > > enough not to suffer from counter wrap? Would it make sense to make the > > SH code hook into their arch tick handler and update the counters from > > there? > > This was the way that the oprofile code used to work. Paul and I were > talking about using a hrtimer to sample performance counters as > opposed to piggy-backing on the tick handler.
Ah, for sampling for sure, simply group a software perf event and a hardware perf event together and use PERF_SAMPLE_READ.
But suppose its a non sampling counter, how do you avoid overflows of the hardware register?
|  |