[lkml]   [2008]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] sched_clock_cpu()
Peter Zijlstra <> writes:

> Hi,
> This is my current proposal to replace the rq->clock stuff (and possibly
> cpu_clock()).
> it _DOESN'T_ boot ;-/ and I seem to have caught a flu that makes my
> whole body hurt like hell, so I'm not getting anything done.

Sorry Peter I think the whole concept is wrong. You're still
at the wrong level.

If you don't fix the underlying sched_clock the results will be always
GIGO (Garbage-In-Garbage-Out). And the best "filtering" will not help
with that if the incoming time is just wrong. And if you fix the
underlying sched_clocks you don't need all that filtering.

That is also why I don't like David's proposal of a Kconfig for this.
It's the wrong way too. Or rather that Kconfig should be always set.

Also I believe x86 sched_clock can be fixed that it will work
properly with some constraints:
- monotonous per CPU only
If you think about it the concept of "jiffies only error" doesn't make sense because it means you can as well use jiffies if you really need inter CPU

- not over deep sleep states on some CPUs.
While modern x86 designs fixed that older ones still have that problem
and it will be always there with us in the embedded world.

I believe both constraints are ok for scheduler purposes. You don't
need to measure idle tasks (and those are the only ones who
go into sleep states) and you can always do all calculations on
the run queue of a specific CPU only.

This means it is not suitable as a printk clock for once, but for
that jiffies is fine anyways.

The rewritten sched_clock I posted the URL to a few times fixes
some of the problems, not all (there was on non monotonity case
left with non p state invariant TSC, i believe it was fixable
though). I unfortunately cannot work on this, but maybe someone is
interested in taking that code over.

[for old kernels]


 \ /
  Last update: 2008-05-05 14:09    [W:0.088 / U:14.892 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site