Horst von Brand wrote:
> > 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.
I don't see how this answers my question. You've said 1 and 2 where:
2. Best performance apps don't switch much. Ok, so they're irrelevant to
"do most apps which _switch often_ ... ?"
1. Runqueue length has no relation to switching time. If we agreed, we
could deduce it's small in most switch-often situations because we
know it's true in most situations generally. I.e., the assertion at
the top of this message is supported.
*But*, runqueue length *does* have a relation to switching time if we
consider the spectrum of interesting high-load applications to be
along this line: On one end, select() based servers that hardly
every switch. On the other end, thread based servers. These do
have larger run queues, and they switch often.
enjoy,
-- Jamie
-
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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:24 EST