* Roman Zippel <zippel@linux-m68k.org> wrote:

quoted text
> > 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.

	Ingo
-
unsubscribe notice
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/