From owner-freebsd-arch@FreeBSD.ORG Thu Feb 21 03:57:31 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55A2316A400; Thu, 21 Feb 2008 03:57:31 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1A73B13C442; Thu, 21 Feb 2008 03:57:31 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m1L3v19M091101; Wed, 20 Feb 2008 22:57:03 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Wed, 20 Feb 2008 17:58:11 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: David Xu In-Reply-To: <47BCEFDB.5040207@freebsd.org> Message-ID: <20080220175532.Q920@desktop> References: <20071219211025.T899@desktop> <18311.49715.457070.397815@grasshopper.cs.duke.edu> <20080112182948.F36731@fledge.watson.org> <20080112170831.A957@desktop> <20080112194521.I957@desktop> <20080219234101.D920@desktop> <20080220101348.D44565@fledge.watson.org> <20080220005030.Y920@desktop> <20080220105333.G44565@fledge.watson.org> <47BCEFDB.5040207@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@FreeBSD.org, Robert Watson , Andrew Gallatin Subject: Re: Linux compatible setaffinity. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 03:57:31 -0000 On Thu, 21 Feb 2008, David Xu wrote: > Robert Watson wrote: >> >> On Wed, 20 Feb 2008, Jeff Roberson wrote: >> >>>> So perhaps this means a slightly more complex API, but not much more >>>> complex. How about: >>>> >>>> int cpuaffinity_get(scope, id, length, mask) >>>> int cpuaffinity_getmax(scope, id, length, mask) >>>> int cpuaffinity_set(scope, id, length, mask) >>>> int cpuaffinity_setmax(scope, id, length, mask) >>>> > > Are these features only for jail or something else which don't care CPU > L2 cache sharing between cores ? since program still can not figure out > L2 sharing information, no way to optimize its thread's cpu arrangement. These are all for binding to specific cpu sets. Potentially with some support for creating something like solaris psets. This is when you have some static information about what processors to use. I think a cache aware solution will be the next process. I have a patch which allows the kernel scheduler to understand the cache hierarchies in the system. This information could be exported to userland if that would be useful. > > Regards, > David Xu >