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

[Jeff Roberson]

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
>