public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Paul Jackson <pj@sgi.com>
Cc: ntl@pobox.com, dino@in.ibm.com, Simon.Derr@bull.net,
	lse-tech@lists.sourceforge.net, akpm@osdl.org,
	nickpiggin@yahoo.com.au, vatsa@in.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpusets+hotplug+preepmt broken
Date: Fri, 13 May 2005 19:23:31 -0700	[thread overview]
Message-ID: <20050513192331.2244ada9.pj@sgi.com> (raw)
In-Reply-To: <20050511135850.3df60a9f.pj@sgi.com>

Two days ago, I wrote:
> Another variation will be forthcoming soon.

Don't apply the following yet, Andrew.  It is untested, and we've not
yet obtained agreement.

I'll sqawk again, if this patch survives long enough to warrant inclusion.

===

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.

Revert the move_task_off_dead_cpu() code to its previous code, before
cpusets were added.  If none of the remaining allowed cpus are online,
then let the task run on any cpu, no limit.  This is a legal fallback,
and indeed one of the possible outcomes of the previous code.  It's just
not so Nice.

If a system administrator doesn't like a task being allowed to run
anywhere as a result of this, then they should clear out a cpuset of the
tasks running in it, before they take the last cpu in that cpuset
offline, and they should use taskset (sched_setaffinity) or other means
to ensure that tasks aren't pinned to a cpu that is about to be taken
offline.

Unless and until someone can make a good case to the contrary, it is not
worth nesting hotplug and cpuset semaphores to attempt to provide a more
subtle fallback, that few people would understand anyway.

At least do one thing right - attach the task to the top_cpuset if we
have to force its cpus_allowed there.  That keeps the tasks apparent
cpuset in sync with its cpus_allowed (any online cpu or CPU_MASK_ALL,
which are roughly equivalent in this context).

Signed-off-by: Paul Jackson <pj@sgi.com>

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;
 		dest_cpu = any_online_cpu(tsk->cpus_allowed);
 
 		/*

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401

  reply	other threads:[~2005-05-14  2:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-11 19:16 [PATCH] cpusets+hotplug+preepmt broken Dinakar Guniguntala
2005-05-11 19:25 ` [Lse-tech] " Paul Jackson
2005-05-11 19:55   ` Paul Jackson
2005-05-11 20:26     ` Nathan Lynch
2005-05-11 20:45       ` Paul Jackson
2005-05-11 19:51 ` Nathan Lynch
2005-05-11 20:42   ` Paul Jackson
2005-05-11 20:58     ` Paul Jackson
2005-05-14  2:23       ` Paul Jackson [this message]
2005-05-14 12:14         ` Nathan Lynch
2005-05-14 17:04           ` Paul Jackson
2005-05-14 17:44             ` Paul Jackson
2005-05-18  4:14               ` Paul Jackson
2005-05-18  9:29               ` [Lse-tech] " Dinakar Guniguntala
2005-05-18 14:48               ` Nathan Lynch
2005-05-18 21:16               ` Paul Jackson
2005-05-14 16:28         ` Srivatsa Vaddagiri
2005-05-12 15:10     ` Dinakar Guniguntala
2005-05-13 12:15       ` [Lse-tech] " Dinakar Guniguntala
2005-05-13  0:34     ` Nathan Lynch
2005-05-13 12:32   ` [Lse-tech] " Dinakar Guniguntala
2005-05-13 17:25     ` Srivatsa Vaddagiri
2005-05-13 19:59       ` Paul Jackson
2005-05-13 20:20         ` Dipankar Sarma
2005-05-13 20:46           ` Nathan Lynch
2005-05-13 21:05             ` Paul Jackson
2005-05-13 21:06             ` Dipankar Sarma
2005-05-13 20:52           ` Paul Jackson
2005-05-13 21:02             ` Dipankar Sarma
2005-05-14  2:58               ` Paul Jackson
2005-05-14 16:09                 ` Srivatsa Vaddagiri
2005-05-14 17:50                   ` Paul Jackson
2005-05-14 17:57                   ` Paul Jackson
2005-05-14 16:30                 ` Nathan Lynch
2005-05-14 17:23                   ` Srivatsa Vaddagiri
2005-05-14 23:17                     ` Nathan Lynch
2005-05-13 19:59     ` Paul Jackson
2005-05-13 21:27     ` Nathan Lynch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050513192331.2244ada9.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=Simon.Derr@bull.net \
    --cc=akpm@osdl.org \
    --cc=dino@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=nickpiggin@yahoo.com.au \
    --cc=ntl@pobox.com \
    --cc=vatsa@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox