Re: [patch] sched: prevent bound kthreads from changingcpus_allowed

[David Rientjes]

On Mon, 9 Jun 2008, Max Krasnyansky wrote:

> > I'd also like to hear why you choose to move your workqueue threads off 
> > their originating cpu.
> CPU isolation. ie To avoid kernel activity on certain CPUs.
> 

This probably isn't something that you should be doing, at least with the 
workqueue threads.  The slab cache reaper, for example, depends on being 
able to drain caches for each cpu and will be neglected if they are moved.

I'm curious why you haven't encountered problems with this while isolating 
per-cpu workqueue threads in cpusets that don't have access to their own 
cpu.

Regardless, we'd need a patch to the slab layer and ack'd by the 
appropriate people at this point to allow the exception.

> Yes cpusets are not only about cpu affinity. But again the behaviour should be
> consistent across the board. cpuset.cpus must apply to all the task in the
> set, not just some of the tasks.
> 

It has always been possible to assign a task to a cpu and then further 
constrict its set of allowable cpus with sched_setaffinity().  So, while 
the cpus_allowed in this case are always a subset of the cpuset's cpus, 
you could still describe this as inconsistent.

> To sum it up here is what I'm suggesting:
> kthread_bind(task, cpu)
> {
>    // Set PF_THREAD_BOUND
>    // Move into root cpuset
>    // Bind to the cpu
> }
> 

kthread_bind() usually happens immediately following kthread_create(), so 
it should already be in the root cpuset.  If it has been forked in a 
different cpuset, however, implicitly moving it may be more harmful than 
any inconsistency that exists in cpus_allowed.

		David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/