Re: [PATCH-v2] tracing: Fix wraparound problems in "uptime" tracer

From: Steven Rostedt
Date: Fri Jul 18 2014 - 13:36:21 EST


On Fri, 18 Jul 2014 10:05:00 -0700
Tony Luck <tony.luck@xxxxxxxxx> wrote:

> On Thu, Jul 17, 2014 at 7:08 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> >> Do we really need to convert to nanoseconds? Couldn't we just return
> >> jiffies:
> >
> > Sure, and we can make it a "counter". That is, the counters don't hide
> > 1000 counts on output.
>
> Can you explain that a bit more ... how do we mark it as a "counter"?

My mistake, I should have said, mark it as not "in_ns"...

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index bda9621..291397e 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -823,7 +823,7 @@ static struct {
{ trace_clock_local, "local", 1 },
{ trace_clock_global, "global", 1 },
{ trace_clock_counter, "counter", 0 },
- { trace_clock_jiffies, "uptime", 1 },
+ { trace_clock_jiffies, "uptime", 0 },
{ trace_clock, "perf", 1 },
ARCH_TRACE_CLOCKS
};

>
> >> u64 notrace trace_clock_jiffies(void)
> >> {
> >> return jiffies_64 - INITIAL_JIFFIES;
> >> }
>
> Hmm it seems that we make it hard for applications to see what HZ
> value the kernel is actually using. All user-facing interfaces should
> convert to USER_HZ (100). So we should say:

Yeah, I remember theses conversations in the past. Basically, HZ is an
internal kernel operation and userspace shouldn't know what it is,
otherwise you may have tools doing whacky things based on it.

Which is a good thing when we eventually get rid of the HZ idea.

>
> u64 notrace trace_clock_jiffies(void)
> {
> return jiffies_64_to_clock_t(jiffies_64 - INITIAL_JIFFIES);
> }
>
> Do we need to change anything in Documentation/trace/ftrace.txt?
>
> Currently it says:
>
> uptime: This uses the jiffies counter and the time stamp
> is relative to the time since boot up.

Yeah, and even if we change it to be converted, I believe that comment
is still correct. It does use the jiffies counter, and the time stamp
is still relative to system boot up.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/