* Roman Zippel <[email protected]> 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.
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
