Re: [PATCH 4/5] tracing/fastboot: Add a time field on the sched_switch entry

From: Frédéric Weisbecker
Date: Sat Oct 18 2008 - 18:34:29 EST


2008/10/18 Tim Bird <tim.bird@xxxxxxxxxxx>:
> I may have lost context here, but what's the purpose of the
> extra timestamp again? If it's just to have zero-based
> timestamps on the ultimate output, can't you just put a single
> special "start" timestamp in the trace log. Then that can
> be subtraced from all tracer-generated stamps in post-processing.
> I'm not familiar enough with the tracer to know if the
> post-processing is done in kernel space. But in any event
> you could use something like scripts/show_delta to get
> relative timestamps (in user space). Right now, scripts/show_delta
> doesn't act like a filter - I'll have to look at that.

Actually the problem is not really to have a zero-based timestamp but I need
to have a timestamp which is the same than the one used by the boot tracer.

If the boot tracer had only to capture one time per entry, I would use
the internal
timestamp of the ring-buffer. But the boot tracer must capture two
times: the call
time of an initcall and the time it returns.

At the same time I want to know the schedule events that occur during
the initcalls
and then the latency they raise. For that I need to have the same
timestamp than the boot
tracer to have a consistent view of these schedule events inside the initcalls.

But you just gave me a new idea :-)
If I split the initcall in two parts: the call and the return, I will
be able to drop these
boot-tracer-specific timestamps and just use the ring-buffer timestamp used
when an entry is appended into the buffer.
And so I can use the usual sched_switch events whithout additional field.

Seems to me really better.

But there is one thing that changes with this new way. It seems that
the ring buffer's timestamp
is based on the sched-clock and so I guess that's why it doesn't start
when the cpu boot but some
times after.

Arjan would you agree with this new time capture system?
--
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/