From: Paul Jackson <pj@sgi.com>
To: David Rientjes <rientjes@google.com>
Cc: clameter@sgi.com, akpm@linux-foundation.org, ak@suse.de,
Lee.Schermerhorn@hp.com, linux-kernel@vger.kernel.org
Subject: Re: [patch 2/2] cpusets: add interleave_over_allowed option
Date: Thu, 25 Oct 2007 20:14:55 -0700 [thread overview]
Message-ID: <20071025201455.acb4e72c.pj@sgi.com> (raw)
In-Reply-To: <alpine.DEB.0.9999.0710251937100.2989@chino.kir.corp.google.com>
David wrote:
> Yes, when using cpusets for resource control. If memory pressure is being
> felt for that cpuset and additional mems are added to alleviate possible
> OOM conditions, it is insufficient to allow tasks within that cpuset to
> continue using memory policies that prohibit them from taking advantage of
> the extra memory.
Well ... "resource control" is a tad thin for a decent "use case".
But ok ... that's a little more compelling.
The user space man pages for set_mempolicy(2) are now even more
behind the curve, by not mentioning that MPOL_INTERLEAVE's mask
might mean nothing, if (1) in a cpuset marked memory_spread_user,
(2) after the cpuset has changed 'mems'.
I wonder if there is any way to fix that. Who does the man pages
for Linux system calls?
Hmmm ... that reminds me ... the period of time between when the
task issues the set_mempolicy(2) MPOL_INTERLEAVE call and when some
cpuset 'mems' change subsequently moves its memory placement is an
anomaly here. During that period of time, the MPOL_INTERLEAVE mask
-does- apply, even if a subset of the 'mems' in the tasks cpuset.
This could result in test cases missing some failures. If they
test with a particular, carefully crafted MPOL_INTERLEAVE mask
that is a proper (strictly less than) subset of the nodes allowed
in the cpuset, they might not notice that their code is broken if
they happen to be in a memory_spread_user cpuset after a 'mems'
change has jammed the entire cpusets 'mems' into their interleave
mask.
Perhaps we should make it so that doing a set_mempolicy(2) call
to set MPOL_INTERLEAVE immediately changes the memory policy to
the cpusets mems_allowed.
A key advantage in doing this would be that the set_mempolicy user
documentation could simply state that the MPOL_INTERLEAVE mask is
ignored when in a cpuset marked memory_spread_user, instead interleaving
over all the memory nodes in the cpuset. This would be quite a bit
simpler and clearer than saying that the cpusets nodes are used only
after subsequent cpuset 'mems' changes.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2007-10-26 3:15 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-25 22:54 [patch 1/2] cpusets: extract mmarray loading from update_nodemask David Rientjes
2007-10-25 22:54 ` [patch 2/2] cpusets: add interleave_over_allowed option David Rientjes
2007-10-25 23:37 ` Christoph Lameter
2007-10-25 23:56 ` David Rientjes
2007-10-26 0:28 ` Christoph Lameter
2007-10-26 1:55 ` Paul Jackson
2007-10-26 2:11 ` David Rientjes
2007-10-26 2:29 ` Paul Jackson
2007-10-26 2:45 ` David Rientjes
2007-10-26 3:14 ` Paul Jackson [this message]
2007-10-26 3:58 ` David Rientjes
2007-10-26 4:34 ` Paul Jackson
2007-10-26 15:37 ` Lee Schermerhorn
2007-10-26 17:04 ` Paul Jackson
2007-10-26 17:28 ` Lee Schermerhorn
2007-10-26 20:21 ` Michael Kerrisk
2007-10-26 20:25 ` Paul Jackson
2007-10-26 20:33 ` Michael Kerrisk
2007-10-26 15:30 ` Lee Schermerhorn
2007-10-26 18:46 ` David Rientjes
2007-10-26 19:00 ` Paul Jackson
2007-10-26 20:45 ` David Rientjes
2007-10-26 21:05 ` Christoph Lameter
2007-10-26 21:08 ` David Rientjes
2007-10-26 21:12 ` Christoph Lameter
2007-10-26 21:15 ` David Rientjes
2007-10-26 21:13 ` Lee Schermerhorn
2007-10-26 21:17 ` Christoph Lameter
2007-10-26 21:26 ` Lee Schermerhorn
2007-10-26 21:37 ` Christoph Lameter
2007-10-29 15:00 ` Lee Schermerhorn
2007-10-29 17:33 ` Paul Jackson
2007-10-29 17:46 ` Lee Schermerhorn
2007-10-29 20:35 ` Christoph Lameter
2007-10-26 21:18 ` David Rientjes
2007-10-26 21:31 ` Lee Schermerhorn
2007-10-26 21:39 ` David Rientjes
2007-10-27 1:07 ` Paul Jackson
2007-10-27 1:26 ` Christoph Lameter
2007-10-27 2:41 ` Paul Jackson
2007-10-27 2:50 ` Christoph Lameter
2007-10-27 5:16 ` Paul Jackson
2007-10-27 6:07 ` Christoph Lameter
2007-10-27 8:36 ` Paul Jackson
2007-10-27 17:47 ` Christoph Lameter
2007-10-27 20:59 ` Paul Jackson
2007-10-27 17:50 ` David Rientjes
2007-10-27 23:19 ` Paul Jackson
2007-10-28 18:19 ` David Rientjes
2007-10-28 23:46 ` Paul Jackson
2007-10-29 1:04 ` David Rientjes
2007-10-29 4:27 ` Paul Jackson
2007-10-29 4:47 ` David Rientjes
2007-10-29 5:45 ` Paul Jackson
2007-10-29 7:00 ` David Rientjes
2007-10-29 7:26 ` Paul Jackson
2007-10-30 22:53 ` David Rientjes
2007-10-30 23:17 ` Paul Jackson
2007-10-30 23:25 ` David Rientjes
2007-10-31 0:03 ` Paul Jackson
2007-10-31 0:05 ` Paul Jackson
2007-10-29 7:15 ` Paul Jackson
2007-10-30 23:12 ` David Rientjes
2007-10-30 23:44 ` Paul Jackson
2007-10-30 23:53 ` David Rientjes
2007-10-31 0:29 ` Paul Jackson
2007-10-29 16:54 ` Lee Schermerhorn
2007-10-29 19:40 ` Paul Jackson
2007-10-29 19:45 ` Paul Jackson
2007-10-29 19:57 ` Paul Jackson
2007-10-29 20:02 ` Paul Jackson
2007-10-27 17:45 ` David Rientjes
2007-10-27 21:22 ` Paul Jackson
2007-10-29 15:10 ` Lee Schermerhorn
2007-10-29 18:41 ` Paul Jackson
2007-10-29 19:01 ` Lee Schermerhorn
2007-10-30 23:17 ` David Rientjes
2007-10-31 0:03 ` Paul Jackson
2007-10-30 22:57 ` David Rientjes
2007-10-30 23:46 ` Paul Jackson
2007-10-26 20:43 ` Lee Schermerhorn
2007-10-26 15:18 ` Lee Schermerhorn
2007-10-26 17:36 ` Christoph Lameter
2007-10-26 18:45 ` David Rientjes
2007-10-26 19:02 ` Paul Jackson
2007-10-27 19:16 ` David Rientjes
2007-10-29 16:23 ` Lee Schermerhorn
2007-10-29 17:35 ` Andi Kleen
2007-10-29 19:35 ` Paul Jackson
2007-10-29 20:36 ` Christoph Lameter
2007-10-29 21:08 ` Andi Kleen
2007-10-29 22:48 ` Paul Jackson
2007-10-30 19:47 ` Paul Jackson
2007-10-30 20:20 ` Lee Schermerhorn
2007-10-30 20:26 ` Paul Jackson
2007-10-30 20:27 ` Andi Kleen
2007-10-26 1:13 ` Paul Jackson
2007-10-26 1:30 ` David Rientjes
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=20071025201455.acb4e72c.pj@sgi.com \
--to=pj@sgi.com \
--cc=Lee.Schermerhorn@hp.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rientjes@google.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