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

From: Con Kolivas
Date: Mon Mar 05 2007 - 17:25:17 EST


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/