Date: Mon, 03 Mar 2008 04:04:30 -0500 From: "Aryeh M. Friedman" <aryeh.friedman@gmail.com> 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: <47CBBF1E.8060701@gmail.com> 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
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47CBBF1E.8060701>