Hi,
On Tue, 2009-11-10 at 09:48 -0800, David Daney wrote:
> Wu Zhangjin wrote:
> [...]
> > + * trace_clock_local(): the simplest and least coherent tracing clock.
> > + *
> > + * Useful for tracing that does not cross to other CPUs nor
> > + * does it go through idle events.
> > + */
> > +u64 trace_clock_local(void)
> > +{
> > + unsigned long flags;
> > + u64 clock;
> > +
> > + raw_local_irq_save(flags);
> > +
> > + clock = mips_timecounter_read();
> > +
> > + raw_local_irq_restore(flags);
> > +
> > + return clock;
> > +}
>
> Why disable interrupts?
>
I got it from kernel/trace/trace_clock.c:
/*
* trace_clock_local(): the simplest and least coherent tracing clock.
*
* Useful for tracing that does not cross to other CPUs nor
* does it go through idle events.
*/
u64 notrace trace_clock_local(void)
{
unsigned long flags;
u64 clock;
/*
* sched_clock() is an architecture implemented, fast, scalable,
* lockless clock. It is not guaranteed to be coherent across
* CPUs, nor across CPU idle events.
*/
raw_local_irq_save(flags);
clock = sched_clock();
raw_local_irq_restore(flags);
return clock;
}
> Also you call the new function mips_timecounter_read(). Since
> sched_clock() is a weak function, you can override the definition with a
> more accurate version when possible. Then you could just directly call
> it here, instead of adding the new mips_timecounter_read() that the
> '[PATCH v7 02/17] tracing: add mips_timecounter_read() for MIPS' adds.
>
Yes, I have tried to override the sched_clock(), but failed on
booting(just hang there). and also, as you know, this version of
mips_timecounter_read() will bring us some overhead, I think it's not a
good idea to enable it for the whole system, so, I only enable it for
ftrace.
Regards,
Wu Zhangjin
