Messages in this thread | | | Date | Sat, 24 Sep 2011 12:21:47 +0900 | From | Tejun Heo <> | Subject | Re: [patch] cpusets: allow PF_THREAD_BOUND kworkers to escape from a cpuset |
| |
Hello,
Sorry about the delay. I'm mostly offline until the end of this month.
On Fri, Sep 23, 2011 at 01:20:51PM -0700, David Rientjes wrote: > > @@ -1382,9 +1383,10 @@ static int cpuset_can_attach(struct cgroup_subsys *ss, struct cgroup *cont, > > * set of allowed nodes is unnecessary. Thus, cpusets are not > > * applicable for such threads. This prevents checking for success of > > * set_cpus_allowed_ptr() on all attached tasks before cpus_allowed may > > - * be changed. > > + * be changed. We also disallow attaching kthreadd, to prevent it's > > + * child from becoming trapped should it then acquire PF_THREAD_BOUND. > > */ > > - if (tsk->flags & PF_THREAD_BOUND) > > + if (tsk->flags & PF_THREAD_BOUND || tsk == kthreadd_task) > > return -EINVAL; > > > > return 0; > > I like this much better, let's wait to hear from Tejun because he may > shead some light on whether PF_THREAD_BOUND is really necessary for > kworkers at all times.
Yes, PF_THREAD_BOUND is necessary. The whole thing depends heavily on per-cpu behavior. In addition, I don't think it makes much sense to put kworkers into a cpuset (or any other resource container) which isn't global to the system. If certain CPU intensive tasks require scheduler based resource limitation, the RTTD would be creating a dedicated worker thread for it and put restrictions on that specific kthread.
Putting kthreadd into a sub cpuset and thus putting restrictions on random kthreads seems like asking for trouble. So, I agree with the suggested approach.
Thank you.
-- tejun
| |