From owner-svn-src-all@FreeBSD.ORG Thu Apr 23 20:05:22 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 B3D1A1065778; Thu, 23 Apr 2009 20:05:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 845E38FC14; Thu, 23 Apr 2009 20:05:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 397A346B3B; Thu, 23 Apr 2009 16:05:22 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id E29838A01C; Thu, 23 Apr 2009 16:05:20 -0400 (EDT) From: John Baldwin To: Robert Watson Date: Thu, 23 Apr 2009 09:59:39 -0400 User-Agent: KMail/1.9.7 References: <200904222140.n3MLebn3068260@svn.freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904230959.39423.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 23 Apr 2009 16:05:20 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=1.1 required=4.2 tests=AWL,DATE_IN_PAST_06_12, RDNS_NONE autolearn=no version=3.2.5 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org 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 20:05:23 -0000 On Thursday 23 April 2009 7:55:53 am Robert Watson wrote: > On Wed, 22 Apr 2009, John Baldwin wrote: > > > Adjust the way we number CPUs on x86 so that we attempt to "group" all > > logical CPUs in a package. We do this by numbering the non-boot CPUs > > by starting with the first CPU whose APIC ID is after the boot CPU and > > wrapping back around to APIC ID 0 if needed rather than always starting > > at APIC ID 0. While here, adjust the cpu_mp_announce() routine to list > > CPUs based on the mapping established by assign_cpu_ids() rather than > > making assumptions about the algorithm assign_cpu_ids() uses. > > Something we'd like to be able to do in the fairly near future is assign work > from one thread/core to another thread/core that is cache-wise "close" to the > current one. For example, if we take a cacheline miss on an mbuf head and the > first line of a packet's data on one CPU, and want to hand it off to another > CPU for further processing, trying to send it somewhere where it's already > quite close, cache-wise, might well be beneficial. Likewise, sending it to > another thread or core that is cache-wise close on the lock protecting the > queue used to pass it between CPUs, would also be nice. > > 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? In theory, this is the job of the topology stuff that is available for the scheduler to use to make similar decisions. The purpose of this patch is to make it easier for system administrators who are using /usr/bin/cpuset to tie tasks to specific cores at more of a macro level by providing a more consistent layout of CPU IDs. Presumably this would matter less if cpuset was topology-aware such that you could specify a set by tuples rather than CPU IDs to identify CPUs. -- John Baldwin