Date: Thu, 23 Apr 2009 13:29:53 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Ivan Voras <ivoras@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r191405 - in head/sys: amd64/amd64 i386/i386 Message-ID: <alpine.BSF.2.00.0904231326240.54334@fledge.watson.org> In-Reply-To: <9bbcef730904230501k26197958tb78d88958bd20654@mail.gmail.com> References: <200904222140.n3MLebn3068260@svn.freebsd.org> <alpine.BSF.2.00.0904231253140.54334@fledge.watson.org> <9bbcef730904230501k26197958tb78d88958bd20654@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1317614271-1240489793=:54334 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 23 Apr 2009, Ivan Voras wrote: > 2009/4/23 Robert Watson <rwatson@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 --621616949-1317614271-1240489793=:54334--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0904231326240.54334>