lkml.org 
[lkml]   [2007]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CFS review
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/

\
 
 \ /
  Last update: 2007-08-01 17:47    [W:1.836 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site