Date: Mon, 3 Mar 2008 02:28:50 -1000 (HST) From: Jeff Roberson <jroberson@chesapeake.net> To: David Xu <davidxu@FreeBSD.org> Cc: cvs-src@FreeBSD.org, Jeff Roberson <jeff@FreeBSD.org>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files src/sys/kern init_main.c kern_cpuset.c kern_thread.c syscalls.master src/sys/sys _types.h cpuset.h proc.h types.h src/lib/libc/sys Symbol.map Message-ID: <20080303022505.P920@desktop> In-Reply-To: <47CBBE21.4060104@freebsd.org> References: <200803020739.m227dNLe039427@repoman.freebsd.org> <47CBBE21.4060104@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Mar 2008, David Xu wrote: > Jeff Roberson wrote: >> jeff 2008-03-02 07:39:22 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/conf files sys/kern init_main.c >> kern_thread.c syscalls.master sys/sys _types.h types.h >> proc.h lib/libc/sys Symbol.map Added files: >> sys/kern kern_cpuset.c sys/sys cpuset.h >> Log: >> Add cpuset, an api for thread to cpu binding and cpu resource grouping >> and assignment. >> - Add a reference to a struct cpuset in each thread that is inherited >> from >> the thread that created it. >> - Release the reference when the thread is destroyed. >> - Add prototypes for syscalls and macros for manipulating cpusets in >> sys/cpuset.h >> - Add syscalls to create, get, and set new numbered cpusets: >> cpuset(), cpuset_{get,set}id() >> - Add syscalls for getting and setting affinity masks for cpusets or >> individual threads: cpuid_{get,set}affinity() >> - Add types for the 'level' and 'which' parameters for the cpuset. This >> will permit expansion of the api to cover cpu masks for other objects >> identifiable with an id_t integer. For example, IRQs and Jails may be >> coming soon. >> - The root set 0 contains all valid cpus. All thread initially belong >> to >> cpuset 1. This permits migrating all threads off of certain cpus to >> reserve them for special applications. >> Sponsored by: Nokia >> Discussed with: arch, rwatson, brooks, davidxu, deischen >> Reviewed by: antoine >> > > The cpuset_setaffinity with command CPU_WHICH_TID may hurt another > process if a weird process is out of the control. > The current code intents to lookup globally a thread has exact thread > id, because thread may be created and exited quickly, and thread ID is reused > quickly too, it is possible the weird process gives an outdated thread ID to > the API, and an irrelvant thread within another process > belongs to same user gets bind to cpus, such problem is very difficult > to be diagnosed when it happens, and it is an administrator is > nightmare. I think there should be a CPU_WHICH_TID_LOCAL command > to limit the searching scope in current process, and in most case, > the CPU_WHICH_TID_LOCAL will be used instead. Does the tid allocator quickly recycle numbers? This would be different from the pid allocator if it does. Basically every syscall that takes a numeric id would be subject to this problem. I expect application programers will more often specify binding from within the running thread using -1. However, there is a seperate problem that is endemic with our current threading support. thread_find() requires the proc lock and returns a pointer to the found thread. However, the proc lock is not sufficient to ensure that the thread is not exiting and recycled after thread_find() returns. I believe virtually every user of this interface may be subject to races. And while were on the subject. Why is it lwpid_t anyway? We don't have lwps, we have threads. Thanks, Jeff > > Regards, > David Xu >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080303022505.P920>