From owner-freebsd-arch@FreeBSD.ORG Thu Feb 21 23:38:35 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 0238B16A408; Thu, 21 Feb 2008 23:38:35 +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 B427C13C4E5; Thu, 21 Feb 2008 23:38:34 +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 m1LNcSwl024554; Thu, 21 Feb 2008 18:38:29 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 21 Feb 2008 13:39:42 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ceri Davies In-Reply-To: <20080221223749.GJ22033@submonkey.net> Message-ID: <20080221133804.T920@desktop> References: <20080112194521.I957@desktop> <20080219234101.D920@desktop> <20080220101348.D44565@fledge.watson.org> <20080220005030.Y920@desktop> <20080220105333.G44565@fledge.watson.org> <47BCEFDB.5040207@freebsd.org> <20080220175532.Q920@desktop> <20080220213253.A920@desktop> <20080221092011.J52922@fledge.watson.org> <20080221223749.GJ22033@submonkey.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , arch@FreeBSD.org, Robert Watson , David Xu , Andrew Gallatin Subject: Re: getaffinity/setaffinity and cpu sets. 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 23:38:35 -0000 On Thu, 21 Feb 2008, Ceri Davies wrote: > On Thu, Feb 21, 2008 at 09:27:41AM +0000, Robert Watson wrote: > >> - You don't mention what happens if a process's cpu set changes to preclude a >> CPU the process has a thread with affinity for. Online, you suggested >> SIGKILL, and I thought maybe a new SIGCPUGONE with a default SIGKILL action >> might be a friendlier model. We should see what Solaris and others do here >> though. I like the idea that the affinity is a guarantee in userspace >> because it means that you can rely on it; I'm OK with the idea that your >> thread always runs on the CPUs you have affinity for unless in the >> SIGCPUGONE handler :-). > > If a processor set disappears from under a process on Solaris, the > process gets moved to the "default" set (or, in other words, they aren't > in a set any more). Yes, that's ok, but what if the process has requested a specific cpu that it's now no longer allowed to access? The sets are seperate from the thread's specific requested binding. If the thread binds to a specific processor within the set and the set disappears what should we do? What if that process was relying on the binding to access cpu specific features such as tsc? Allowing it to migrate could then break the code. Thanks, Jeff > > Ceri > -- > That must be wonderful! I don't understand it at all. > -- Moliere >