Date: Wed, 20 Feb 2008 08:06:43 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: Linux compatible setaffinity. Message-ID: <Pine.GSO.4.64.0802200750350.6668@sea.ntplx.net> In-Reply-To: <20080219234101.D920@desktop> References: <20071219211025.T899@desktop> <18311.49715.457070.397815@grasshopper.cs.duke.edu> <20080112182948.F36731@fledge.watson.org> <20080112170831.A957@desktop> <Pine.GSO.4.64.0801122240510.15683@sea.ntplx.net> <20080112194521.I957@desktop> <20080219234101.D920@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 19 Feb 2008, Jeff Roberson wrote: > On Sat, 12 Jan 2008, Jeff Roberson wrote: > >> On Sat, 12 Jan 2008, Daniel Eischen wrote: >> >>> On Sat, 12 Jan 2008, Jeff Roberson wrote: >>> >>>> Now, there is one problem with the linux api that I want to discuss >>>> before I commit it. The current patch always works on curthread. >>>> However, the api allows for setting the binding of a pid. I believe, >>>> although I'm not certain, that pids and tids in linux are in the same >>>> number space. It's not clear to me whether you can set an affinity for >>>> an entire process and have it effect an individual thread or whether you >>>> set it on a thread by thread basis. When supplying a non-curproc pid do >>>> you bind all threads in the target process? >>>> >>>> Are our tids and pids in the same number space? And are they available >>>> to application programmers? I haven't followed that very carefully. >>> >>> I believe marcel made tids and pids disjoint so that any pid is >>> never equal to any tid. But regardless, I don't think we want >>> to rely on that. I would prefer the Solaris approach of specifying >>> what we want (pid, tid, jail id, etc) as an argument in the API >>> so there is no confusion. >> >> Yes, I would prefer that as well I believe. So I'll add an extra parameter >> and in the linux code we'll use whatever their default is. Of course the >> initial implementation will still only support curthread but I plan on >> finishing the rest before 8.0 is done. > > So what does everyone think of something like this: > > int cpuaffinity(int cmd, long which, int masksize, unsigned *mask); > > #define AFFINITY_GET 0x1 > #define AFFINITY_SET 0x2 > #define AFFINITY_PID 0x4 > #define AFFINITY_TID 0x8 > > I'm not married to any of these names. If you know of something that would > be more regular please comment. I take it 'cmd' is either AFFINITY_GET or AFFINITY_SET, and which is AFFINITY_PID or AFFINITY_TID. Is there a reason why, for 2 different arguments to cpuaffinity(), the flags are disjoint? It almost seems like you wanted: int cpuaffinity(int flags, int masksize, unsigned *mask) I prefer the API you specified, keeping 'cmd' and 'which' as separate arguments. Is masksize in bytes or in units of unsigned? Do we need helper functions/macros for the mask? Like sigemptyset, sigaddset, etc? -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0802200750350.6668>