Re: [ck] Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

[Con Kolivas]

On Tuesday 06 March 2007 05:23, Al Boldi wrote:
> Con Kolivas wrote:
> > Gears just isn't an interactive task and just about anything but gears
> > would be a better test case since its behaviour varies wildly under
> > different combinations of graphics cards, memory bandwidth, cpu and so
> > on.
>
> What about reflect?  It has the same problem.
>
> > I'm not even sure what you're trying to prove with gears.
>
> RSDL fairness.
>
> Ok, try this:
> # gears & gears &
> Both run smoothly.
> # nice gears & nice gears &
> Both run smoothly.
>
> Now:
> # gears & nice -10 gears &
> Both stutter.
>
> But:
> # gears & nice --10 gears &
> Both run smoothly.
>
> Something looks fishy with nice levels.

Hah I just wish gears would go away. If I get hardware where it runs at just 
the right speed it looks like it doesn't move at all. On other hardware the 
wheels go backwards and forwards where the screen refresh rate is just 
perfectly a factor of the frames per second (or something like that). 

This is not a cpu scheduler test and you're inferring that there are cpu 
scheduling artefacts based on an application that has bottlenecks at 
different places depending on the hardware combination. 

To imply something is fishy with nice levels, do a test that _only_ uses cpu 
(and not the bus, memory bandwidth, the gpu and has driver interactions) and 
prove that there is something wrong. What happens to other resources on the 
machine the cpu scheduler has no control over. The -rt tree tries to address 
these factors for example but it's a huge - some would say insurmountable - 
thing to try and manage at all levels on a general purpose operating system. 
The cpu is proportioned out very fairly with rsdl on both quota and latency 
according to nice vs cpu usage. When something is fully cpu bound on rsdl its 
average and maximum latency will be greater than something that only 
intermittently uses cpu. The (somewhat lengthy and not easily digestible) 
docs describe how you can model what these latencies will be.

> Otherwise, your scheduler looks great!

Thanks!

-- 
-ck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/