A different metric for scheduler optimisation

[Jamie Lokier]

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