From: Paul Jackson <pj@sgi.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: anton@samba.org, akpm@osdl.org, Simon.Derr@bull.net,
linux-kernel@vger.kernel.org, ak@suse.de, iwamoto@valinux.co.jp
Subject: Re: [Patch 4/4] cpusets top mask just online, not all possible
Date: Sat, 11 Sep 2004 19:21:56 -0700 [thread overview]
Message-ID: <20040911192156.1da7c636.pj@sgi.com> (raw)
In-Reply-To: <1094923728.3997.10.camel@localhost>
Andrew,
Discard this 4/4 patch for "online" - I've got a better one
coming in a few hours. (If you want to keep this 4/4 patch
and have me send the next one relative to it, that works too -
just ask.)
The problem is that what's online, and what cpusets decrees, might
conflict.
The solution is simple: online wins.
This is for the simple reason that it is better to run something in the
wrong place, than to refuse to run it. The kernel, the apps and the
users all cope better with misplacement than with starvation.
There are only a handful of places that cpusets hooks into the kernel,
none of them on critical code paths. My upcoming patch will guarantee
to always provide 'online' CPUs and Memory Nodes in these places, using
the current cpu_online_map and node_online_map.
If what the user configured in their cpuset is still online, then no
problem - they get what they asked for.
If they setup a cpuset, then unplug the CPUs or Memory Nodes that cpuset
uses, but don't update their cpuset config, then tough - I'll give them
some CPUs and Memory Nodes that are online instead. If they don't like
my online choices, then they should fix their cpuset config to be valid
again.
Fix should require a couple lines of cpumask and nodemask logic in a
handful of cpuset routines, and a few other related cpuset code tweaks
... right up my alley.
Dave,
Just as code in kernel/sched.c:move_task_off_dead_cpu()
updates the affected tasks cpus_allowed to move off a dead
CPU, calling cpuset_cpus_allowed() to get a new list of
candidate CPUs to be set in task->cpus_allowed, similarly I
expect that disabling a Memory Node should result in some
"move_task_off_dead_memory()" routine, that called a cpuset
routine to be called "cpuset_mems_allowed()", to get a new
list of Memory Nodes, to be set in task->mems_allowed.
Does this expectation fit for you? If so, let me know when
you want the"cpuset_mems_allowed()" routine - or take a stab
at it yourself if you find that easier.
There are other ways to skin this cat - feel free to offer
such up if that fits your work better.
But, for now, I leave the issue of how to update the tasks
mems_allowed field, when a Memory Node goes offline, in your
hands, for the next step.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373
next prev parent reply other threads:[~2004-09-12 2:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-11 8:28 [Patch 0/4] four small cpuset patches Paul Jackson
2004-09-11 8:28 ` [Patch 1/4] cpusets display allowed masks in proc status Paul Jackson
2004-09-11 8:28 ` [Patch 2/4] cpusets simplify cpus_allowed setting in attach Paul Jackson
2004-09-11 8:28 ` [Patch 3/4] cpusets remove useless validation check Paul Jackson
2004-09-11 8:28 ` [Patch 4/4] cpusets top mask just online, not all possible Paul Jackson
2004-09-11 14:10 ` Anton Blanchard
2004-09-11 17:07 ` Paul Jackson
2004-09-11 17:28 ` Dave Hansen
2004-09-12 2:21 ` Paul Jackson [this message]
2004-09-12 4:43 ` Dave Hansen
2004-09-12 5:35 ` Paul Jackson
2004-09-12 5:42 ` Paul Jackson
2004-09-11 17:39 ` Dave Hansen
2004-09-11 18:55 ` Andi Kleen
2004-09-12 2:29 ` Paul Jackson
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=20040911192156.1da7c636.pj@sgi.com \
--to=pj@sgi.com \
--cc=Simon.Derr@bull.net \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=anton@samba.org \
--cc=haveblue@us.ibm.com \
--cc=iwamoto@valinux.co.jp \
--cc=linux-kernel@vger.kernel.org \
/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