svn commit: r191405 - in head/sys: amd64/amd64 i386/i386
Robert Watson
rwatson at FreeBSD.org
Thu Apr 23 12:29:54 UTC 2009
On Thu, 23 Apr 2009, Ivan Voras wrote:
> 2009/4/23 Robert Watson <rwatson at freebsd.org>:
>
>> Do you have any ideas about ways to usefully represent and manage concepts
>> like "pick a close CPU" or "the set of CPUs that are close"? For example,
>> if I have available a flow identifier, hashing to one of a set of available
>> CPUs is easy, but what would you suggest as an efficient representation to
>> hash from a set of close available CPUs rather than the entire pool?
>
> Excuse me if I'm missing the point but isn't this already done by ULE and
> for almost the same reasons? Shouldn't the scheduler (or its topology
> infrastructure if it's separated from the scheduler) be the best place to do
> it?
Yes, the scheduler will presumably provide the abstractions we're interested
in in order to implement this sort of policy. However, the scheduler's notion
of "strictly ordered events" is represented by a thread, and threads scale to
several thousand per machine. The network stack's notion of "strictly ordered
events" is represented by a flow, and we need to be able to handle millions of
those at once. The mapping between flows and threads is something the network
stack is best suited to do, since it will be passing around and ordering the
work, but with the help of appropriate abstractions from the scheduler so that
it knows how many and which threads exist to do the work, and so that it can
use scheduler-provided metrics, such as CPU topology, to make reasonable
choices about placement of work when there's flexibility in the ordering.
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the svn-src-all
mailing list