Kevin Grittner wrote:
> Sure, but the architecture of those products is based around all the
> work being done by "engines" which try to establish affinity to
> different CPUs, and loop through the various tasks to be done. You
> don't get a context switch storm because you normally have the number
> of engines set at or below the number of CPUs. The down side is that
> they spend a lot of time spinning around queue access to see if
> anything has become available to do -- which causes them not to play
> nice with other processes on the same box.
>
This is just misleading at best. I'm sorry, but (in particular) UNIX
systems have routinely
managed large numbers of runnable processes where the run queue lengths are
long without such an issue. This is not an issue with the number of
runnable threads,
but with the way that they wait and what they do.
The context switch rate reported does not indicate processes using their
timeslices
productively, unless the load is from a continuous stream of trivial
RPCs and that
doesn't stack up with the good performance and then problematic load
that the
OP reported.
