A different metric for scheduler optimisation

[Horst von Brand]

Jamie Lokier <lkd en tantalophile.demon.co.uk> said:
> Everyone who talk of the importance of cache reloads around context
> switches should bear in mind:
> 
>   The typical run queue size is *not* the relevant figure.
> 
> The relevant question for scheduler optimisation is:
> 
>   `` What is the typical  (Switch Rate / Average Run Queue)  ratio?  ''
> 
> 
> I'd be surprised if that doesn't support the current linear scan, but
> the idea is worth some figures.
> 
> Does anyone have measurements that support this assertion: that most
> apps which switch often have tiny run queues?

It's easy to see it is not: Assuming a constant amount of work to be done
(and disregarding the switching cost for a moment), the switch rate is
simply inversely proportional to the service time, queue length doesn't
enter the equation at all. If you consider a closed system, with just a CPU
in it where jobs are recicled to the queue, you also see that the runqueue
length is just the number of jobs in the system, no relation at all to the
switching time. This model is very crude, but essentially right. Remember
the people saying that you can get the same work done with runqueue length
1 or 20, depending on application design?

In case your application switches rapidly, it is thrashing the cache, which
is crucial for performance with current CPUs. You simply don't want to do
that, ever. You get best performance by _never_ switching unless forced to
do so, but that isn't realistic.
-- 
Horst von Brand                             vonbrand en sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile                               +56 32 672616


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/