[Top] [All Lists]

Re: [PATCH v8 01/16] tracing: convert trace_clock_local() as weak functi

To: Thomas Gleixner <>
Subject: Re: [PATCH v8 01/16] tracing: convert trace_clock_local() as weak function
From: Michal Simek <>
Date: Mon, 16 Nov 2009 16:47:09 +0100
Cc: Wu Zhangjin <>,, Ralf Baechle <>, Frederic Weisbecker <>, Ingo Molnar <>, Nicholas Mc Guire <>, David Daney <>, Richard Sandiford <>, Patrik Kluba <>, "Maciej W . Rozycki" <>,,,,
In-reply-to: <alpine.LFD.2.00.0911161559280.24119@localhost.localdomain>
Original-recipient: rfc822;
References: <> <> <alpine.LFD.2.00.0911161559280.24119@localhost.localdomain>
User-agent: Thunderbird (X11/20090625)
Thomas Gleixner wrote:
On Sat, 14 Nov 2009, Wu Zhangjin wrote:

From: Wu Zhangjin <>

trace_clock_local() is based on the arch-specific sched_clock(), in X86,
it is tsc(64bit) based, which can give very high precision(about 1ns
with 1GHz). but in MIPS, the sched_clock() is jiffies based, which can
give only 10ms precison with 1000 HZ. which is not enough for tracing,
especially for Real Time system.

so, we need to implement a MIPS specific sched_clock() to get higher
precision. There is a tsc like clock counter register in MIPS, whose
frequency is half of the processor, so, if the cpu frequency is 800MHz,
the time precision reaches 2.5ns, which is very good for tracing, even
for Real Time system.

but 'Cause it is only 32bit long, which will rollover quickly, so, such
a sched_clock() will bring with extra load, which is not good for the
whole system. so, we only need to implement a arch-specific
trace_clock_local() for tracing. as a preparation, we convert it as a
weak function.

Hmm, I'm not convinced that this is really a huge overhead.
First of all the rollover happens once every 10 seconds on a 800MHz
Secondly we have a lockless implementation of extending 32bit counters
to 63 bit which is used at least by ARM to provide a high resolution
sched_clock implementation. See include/linux/cnt32_63.h and the users
in arch/

But that's a problem which can be discussed seperately and does not
affect the rest of the tracing infrastructure. I really would
recommend that you implement a sched_clock for the r4k machines based
on cnt32_63 and measure the overhead. Having a fine granular
sched_clock in general is probably not a bad thing.

please cc me on this discuss too. I have working ftrace implementation in my tree and I need improve timing too. I have similar patch as MIPS use. But I am not able to use it via timecounters. Something is weird there that's why I am open to find out any sensible and accepted solution.




Michal Simek, Ing. (M.Eng)
w: p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux -
Microblaze U-BOOT custodian

<Prev in Thread] Current Thread [Next in Thread>