Re: CFS review

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Wed, 1 Aug 2007, Ingo Molnar wrote:

> > > in that case 'top' accounting symptoms similar to the above are not 
> > > due to the scheduler starvation you suspected, but due the effect of 
> > > a low-resolution scheduler clock and a tightly coupled 
> > > timer/scheduler tick to it.
> > 
> > Well, it magnifies the rounding problems in CFS.
> 
> why do you say that? 2.6.22 behaves similarly with a low-res 
> sched_clock(). This has nothing to do with 'rounding problems'!
> 
> i tried your fl.c and if sched_clock() is high-resolution it's scheduled 
> _perfectly_ by CFS:
> 
>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>   5906 mingo     20   0  1576  244  196 R 71.2  0.0   0:30.11 l
>   5909 mingo     20   0  1844  344  260 S  9.6  0.0   0:04.02 lt
>   5907 mingo     20   0  1844  508  424 S  9.5  0.0   0:04.01 lt
>   5908 mingo     20   0  1844  344  260 S  9.5  0.0   0:04.02 lt
> 
> if sched_clock() is low-resolution then indeed the 'lt' tasks will 
> "hide":
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  2366 mingo     20   0  1576  248  196 R 99.9  0.0   0:07.95 loop_silent
>     1 root      20   0  2132  636  548 S  0.0  0.0   0:04.64 init
> 
> but that's nothing new. CFS cannot conjure up time measurement methods 
> that do not exist. If you have a low-res clock and if you create an app 
> that syncs precisely to the tick of that clock via timers that run off 
> that exact tick then there's nothing the scheduler can do about it. It 
> is false to charachterise this as 'sleeper starvation' or 'rounding 
> error' like you did. No amount of rounding logic can create a 
> high-resolution clock out of thin air.

Please calm down. You apparantly already get worked up about one of the 
secondary problems. I didn't say 'sleeper starvation' or 'rounding 
error', these are your words and it's your perception of what I said.

sched_clock() can have a low resolution, which can be a problem for the 
scheduler. This is all this program demonstrates. If and how this problem 
should be solved is a completely different issue, about which I haven't 
said anything yet and since it's not that important right now I'll leave 
it at that for now.

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