On Thu, 23 Apr 2009, Ivan Voras wrote:
2009/4/23 Robert Watson <rwat...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
