From owner-svn-src-all@FreeBSD.ORG Thu Apr 23 12:29:54 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CEDD1065670; Thu, 23 Apr 2009 12:29:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2364B8FC1A; Thu, 23 Apr 2009 12:29:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B728446B1A; Thu, 23 Apr 2009 08:29:53 -0400 (EDT) Date: Thu, 23 Apr 2009 13:29:53 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: <9bbcef730904230501k26197958tb78d88958bd20654@mail.gmail.com> Message-ID: References: <200904222140.n3MLebn3068260@svn.freebsd.org> <9bbcef730904230501k26197958tb78d88958bd20654@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1317614271-1240489793=:54334" Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin Subject: Re: svn commit: r191405 - in head/sys: amd64/amd64 i386/i386 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 12:29:54 -0000 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 : > >> 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--