[lkml]   [2008]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 6/6] tracing/fastboot: Print ktime of sched events when boot tracing
2008/10/10 Ingo Molnar <>:
> * Frederic Weisbecker <> wrote:
>> When we use the boot tracer, we want the sched events to be printed
>> with the same timestamp than initcall events. So we have to create a
>> new type of entry which contains sched event attributes and the ktime
>> of the creation of the entry. Then the output is handled by the boot
>> tracer.
> hm, i think that's unnecessary duplication. Please extend the context
> switch trace entries to be useful for the boot tracer as well:

Ok. I will change it in V2.

> also, ktime_get() can be a quite complex function with dependency on
> xtime_lock - that inverts with the rq lock - so this can lock up
> sporadically when called from within the scheduler.
> it would be _much_ simpler to standardize the initcall timestamps on
> cpu_clock() instead. That too is a good global clock and starts at zero
> during bootup. Ok?

Hmm. Ok, I will pick what I saw about cpu_clock() in printk.c

> Your other patches look good and i've applied them to
> tip/tracing/fastboot:
> 3981ce9: tracing/fastboot: use sched switch tracer from boot tracer
> 563582a: tracing/ftrace: remove unused code in sched_switch tracer
> d25b1ce: tracing/ftrace: fix a race condition in sched_switch tracer

Thanks. But are you really sure about d25b1ce?
Steven suggested some changes. But it doesn't matter, I can apply his
suggestions on top of this applied patch.

 \ /
  Last update: 2008-10-10 16:51    [W:0.152 / U:1.056 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site