* Martin Schwidefsky <[EMAIL PROTECTED]> wrote: > On Mon, 2007-08-20 at 20:08 +0200, Ingo Molnar wrote: > > For sched_clock()'s behavior while the virtual CPU is idle: my current > > idea for that is the patch below (a loosely analoguous problem exists > > with nohz/dynticks): it makes sched_clock() valid across idle periods > > too and uses wall-clock time for that. > > Ok, that would mean that sched_clock can just return the virtual cpu > time and the two hooks starts and stops the idle periods as far as the > scheduler is concerned. In this case we can use the patch from Jan > with the new implementation for sched_clock and add the two hooks to > the places where the cpu-idle notifiers are done (do_monitor_call and > default_idle). In fact this could be an idle-notifier. Hmm, I take a > closer look tomorrow when I'm back at the office.
ok. Just to make it sure wrt. release-management: you said s390 sched_clock() is currently at least as precise as stime/utime - so this would suggest that there is no regression over v2.6.22? Regardless of whether it's a live regression or not, i think we want the nohz improvement (and the s390 patch if the callbacks are OK to you) in .23, and we want to migrate all users of "raw" sched_clock() [blktrace, softlockup-detector, print-timestamps, etc.] over to the better cpu_clock() interface. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/