Date: Fri, 22 Feb 2008 15:53:00 +0000 From: Ceri Davies <ceri@submonkey.net> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Daniel Eischen <deischen@FreeBSD.org>, arch@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, David Xu <davidxu@FreeBSD.org>, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: getaffinity/setaffinity and cpu sets. Message-ID: <20080222155300.GA72691@submonkey.net> In-Reply-To: <20080221133804.T920@desktop> References: <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> <20080221133804.T920@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Thu, Feb 21, 2008 at 01:39:42PM -1000, Jeff Roberson wrote:
>
> 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.
OK, I was talking about processor sets; in Solaris, binding to a set
(pset_bind()) and binding to a specific processor (processor_bind()) are
different operations.
A processor that has LWPs bound to it specifically (with processor_bind())
may not be taken offline or marked as spare, unless the operation is forced,
whereupon forcing removes the binding. Since this is an administrative
choice, it's acceptable.
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFHvu/cocfcwTS3JF8RAqyYAJ9ILwO5kCBIzm6+m4nzR7zGh0U50ACeP6Ba
EezrE/EO0o/7cp5E2ryb918=
=qdXO
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080222155300.GA72691>