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/
