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 [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]
