Re: [PATCH] cpusets+hotplug+preepmt broken

[Nathan Lynch <ntl@pobox.com>]

Paul Jackson wrote:
> 
> Ah to heck with it.  This subtle distinction over what level of cpuset
> we fall back to when a hot unplug leaves a task with no online cpuset in
> its current allowed set is not worth it.
> 
> Every variation I consider is either sufficiently complicated that I
> can't be sure it's right, or sufficiently simple that it's obviously
> broken.

Heh, I feel your pain.

> diff -Naurp 2.6.12-rc1-mm4.orig/kernel/sched.c 2.6.12-rc1-mm4/kernel/sched.c
> --- 2.6.12-rc1-mm4.orig/kernel/sched.c	2005-05-13 18:39:54.000000000 -0700
> +++ 2.6.12-rc1-mm4/kernel/sched.c	2005-05-13 19:02:49.000000000 -0700
> @@ -4301,7 +4301,8 @@ static void move_task_off_dead_cpu(int d
>  
>  	/* No more Mr. Nice Guy. */
>  	if (dest_cpu == NR_CPUS) {
> -		tsk->cpus_allowed = cpuset_cpus_allowed(tsk);
> +		cpus_setall(tsk->cpus_allowed);
> +		tsk->cpuset = &top_cpuset;

Hmm, tsk->cpuset will break the build if !CONFIG_CPUSETS, no?  Plus,
the task's original cpuset->count will be unbalanced and it will never
be released, methinks.

As a short-term (i.e. 2.6.12) solution, would it be terrible to set
tsk->cpus_allowed to the default value without messing with the
cpuset?  That is, is it Bad for a task's cpus_allowed to be a superset
of its cpuset's cpus_allowed?  I ran Dinakar's test on 2.6.12-rc4 +
this proposed "fix" on ppc64 without any crashes or warnings, but I
would need you to confirm that this doesn't violate some fundamental
cpuset constraint.

However, I think making a best effort to honor the task's cpuset is a
reasonable goal in this context.  But it will require some nontrivial
changes to the code for migrating tasks off the dead cpu, as well as
some changes to the cpuset code.  Not 2.6.12 material.

I'll patch soon.

Nathan