Messages in this thread | | | Date | Mon, 12 Jul 2010 23:59:08 -0700 | From | Sridhar Samudrala <> | Subject | Re: [PATCH repost] sched: export sched_set/getaffinity to modules |
| |
On 7/4/2010 2:00 AM, Michael S. Tsirkin wrote: > On Fri, Jul 02, 2010 at 11:06:37PM +0200, Oleg Nesterov wrote: > >> On 07/02, Peter Zijlstra wrote: >> >>> On Fri, 2010-07-02 at 11:01 -0700, Sridhar Samudrala wrote: >>> >>>> Does it (Tejun's kthread_clone() patch) also inherit the >>>> cgroup of the caller? >>>> >>> Of course, its a simple do_fork() which inherits everything just as you >>> would expect from a similar sys_clone()/sys_fork() call. >>> >> Yes. And I'm afraid it can inherit more than we want. IIUC, this is called >> from ioctl(), right? >> >> Then the new thread becomes the natural child of the caller, and it shares >> ->mm with the parent. And files, dup_fd() without CLONE_FS. >> >> Signals. Say, if you send SIGKILL to this new thread, it can't sleep in >> TASK_INTERRUPTIBLE or KILLABLE after that. And this SIGKILL can be sent >> just because the parent gets SIGQUIT or abother coredumpable signal. >> Or the new thread can recieve SIGSTOP via ^Z. >> >> Perhaps this is OK, I do not know. Just to remind that kernel_thread() >> is merely clone(CLONE_VM). >> >> Oleg. >> > > Right. Doing this might break things like flush. The signal and exit > behaviour needs to be examined carefully. I am also unsure whether > using such threads might be more expensive than inheriting kthreadd. > > Should we just leave it to the userspace to set the cgroup/cpumask after qemu starts the guest and the vhost threads?
Thanks Sridhar
| |