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.
Would lack of this cause binaries compiled against a non-cpuset
schedular to panic a cpuset one? Specifically when I was attempting to
verify the performence gain I commented out all *_affinity items in
sched_ule.c and kern_cpuset.c and it booted fine but panicked if any
forks from the shell occured (i.e. tcsh came up fine in single user mode
but *ANY* external command sent it into a panic)
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
