[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100701153112.GA13511@console-pimps.org>
Date: Thu, 1 Jul 2010 16:31:12 +0100
From: MattFleming <matt@...sole-pimps.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Will Deacon <will.deacon@....com>, paulus <paulus@...ba.org>,
stephane eranian <eranian@...glemail.com>,
Robert Richter <robert.richter@....com>,
Paul Mundt <lethal@...ux-sh.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Cyrill Gorcunov <gorcunov@...il.com>,
Lin Ming <ming.m.lin@...el.com>,
Yanmin <yanmin_zhang@...ux.intel.com>,
Deng-Cheng Zhu <dengcheng.zhu@...il.com>,
David Miller <davem@...emloft.net>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 00/11] perf pmu interface -v2
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.
> 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.
--
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