Re: cpusets and kthreads, inconsistent behaviour

[Max Krasnyansky]

David Rientjes wrote:
> On Tue, 10 Jun 2008, Max Krasnyansky wrote:
> 
>> Hmm, technically you are correct of course. But we do not have any other
>> kernel tasks besides kthreads. All the kernel tasks I have on my machines have
>> kthreadd as their parent.
>> And I'm not aware of any kernel code that changes affinity mask of a
>> user-space task without paying attention to the cpuset the task belongs to. If
>> you know of any we should fix it because it'd clearly be a bug.
>>
> 
> This is why it shouldn't belong in the sched or kthread code; the 
> discrepency that you point out between p->cpus_allowed and 
> task_cs(p)->cpus_allowed is a cpuset created one.
I guess I do not see how the kernel task case is different from the
sched_setaffinity(). ie sched_setaffinity() is in the scheduler but it deals
with cpusets.

Also in this case the discrepancy is created _not_ by the cpuset, it's created
due to the lack of the appropriate API. In other words if we had something
kthread_setaffinty() from day one this would have been a non-issue :).

> So to avoid having tasks with a cpus_allowed mask that is not a subset of 
> its cpuset's set of allowable cpus, the solution would probably be to add 
> a flavor of cpuset_update_task_memory_state() for a cpus generation value.
Post policing would not work well in some scenarios due to lag time. ie By the
time cpusets realized that some kthread is running on the wrong cpus it maybe
too late.
We should just enforce cpuset constraint when kthreads change their affinity
mask, just like sched_setaffinity() already does.

Max
--
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/