[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1004152025240.3625@localhost.localdomain>
Date: Thu, 15 Apr 2010 20:26:57 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Michal Simek <michal.simek@...alogix.com>
cc: steve@...idescorp.com, Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>,
Wu Zhangjin <wuzhangjin@...il.com>
Subject: Re: sched_clock - microblaze
On Thu, 15 Apr 2010, Michal Simek wrote:
> Steven J. Magnani wrote:
> > Michal,
> >
> > On Thu, 2010-04-15 at 16:55 +0200, Michal Simek wrote:
> >
> > > Is unimplemented sched_clock the reason why ftrace not show fine grain
> > > time?
> > >
> > > Or is there any other thing which is wrong?
> > >
> >
> > I think that's it. On my platform we have a free-running 1 MHz counter
> > so I implemented a platform sched_clock for that, and I get nice ftrace
> > times.
> >
> > 0) + 65.000 us | finish_task_switch();
> > 0) | lock_sock_nested() {
> > 0) + 52.000 us | local_bh_disable();
> > 0) + 53.000 us | local_bh_enable();
> > 0) ! 264.000 us | }
>
> I don't understand why I should add any "new" free running counter because we
> have one free running counter which do it (clocksource timer - timer1). Or am
> I missing something?
No, you just can use the clocksource for it. We have that separation
as on x86 we want to use the TSC even if it is not usable for time
keeping as it is the fastest accesible clock in x86. So for your case
you can just use your main clocksource as sched_clock and be done.
Thanks,
tglx
--
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