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@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@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/