Date: Wed, 20 Feb 2008 12:33:29 -1000 (HST) From: Jeff Roberson <jroberson@chesapeake.net> To: Daniel Eischen <deischen@freebsd.org> Cc: arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: Linux compatible setaffinity. Message-ID: <20080220123209.V920@desktop> In-Reply-To: <Pine.GSO.4.64.0802200750350.6668@sea.ntplx.net> 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> <Pine.GSO.4.64.0802200750350.6668@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 20 Feb 2008, Daniel Eischen wrote: > 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. > Yes, I'll either do that or have seperate get/set syscalls. > Is masksize in bytes or in units of unsigned? Do we need helper > functions/macros for the mask? Like sigemptyset, sigaddset, etc? I have macros copied from FD_SET, as CPU_SET, CPU_ISSET, etc. This will go in sys/sched.h. > > -- > DE >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080220123209.V920>