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

David Xu davidxu at
Mon Mar 3 08:59:02 UTC 2008

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 
>   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.

David Xu

More information about the cvs-src mailing list