Re: register_timer_hook use in arch/sh/oprofile

Paul Mundt
2009-06-24T12:26:42Z

On Wed, Jun 24, 2009 at 02:17:50PM +0200, Ingo Molnar wrote:
>
> * Paul Mundt <lethal@linux-sh.org> wrote:
>
> > In practice oprofile has never been a good fit for these sorts of
> > counters, so this has fairly limited use. If there's a way to
> > wiggle these types of counters in to the new perf_counter API,
> > then I'll convert that over and just kill the old oprofile driver
> > off completely. Barring that, I'll just end up converting it over
> > to hrtimers as well, so don't let that stop you from ripping out
> > the timer hook bits.
> >
> > Most of this code predates hrtimers anyways, and it also predates
> > the timer hook, which is only something that we converted to some
> > years back.
>
> Note, the current initial upstream SH support for perfcounters:
>
> arch/sh/include/asm/perf_counter.h:#define set_perf_counter_pending() do { } while (0)
> arch/sh/include/asm/unistd_32.h:#define __NR_perf_counter_open 336
> arch/sh/include/asm/unistd_64.h:#define __NR_perf_counter_open 364
> arch/sh/kernel/syscalls_32.S: .long sys_perf_counter_open
> arch/sh/kernel/syscalls_64.S: .long sys_perf_counter_open
>
> Should already give you hrtimers straight away.
>
> To test it, could you try to run 'perf top' after:
>
> cd tools/perf/
> make install
>
> It should display a hrtimer driven kernel profile already. You can
> increase/decrease the frequency of sampling by using -F option - say
> 'perf top -F 10000' should sample at 10 KHz.
>
> Please let me know if any of this does not work as expected.
>
Yes, that all works fine. My comment was more in reference to the
hardware performance counters that don't have IRQs of their own, which
still need to be tied in to the perf_counter API.