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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
