From: David Rientjes <rientjes@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Miao Xie <miaox@cn.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Paul Menage <paul@paulmenage.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch v2 for-3.2-rc3] cpusets: stall when updating mems_allowed for mempolicy or disjoint nodemask
Date: Fri, 18 Nov 2011 15:53:00 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.1111181549460.24487@chino.kir.corp.google.com> (raw)
In-Reply-To: <20111117160019.c8bd45ba.akpm@linux-foundation.org>
On Thu, 17 Nov 2011, Andrew Morton wrote:
> Nothing in this changelog makes me understand why you think we need this
> change in 3.2. What are the user-visible effects of this change?
>
Kernels where MAX_NUMNODES > BITS_PER_LONG may temporarily see an empty
nodemask in a tsk's mempolicy if its previous nodemask is remapped onto a
new set of allowed cpuset nodes where the two nodemasks, as a result of
the remap, are now disjoint. This fix is a bandaid so that we never
optimize the stores to tsk->mems_allowed because they intersect if tsk
also has an existing mempolicy, so that prevents the possibility of seeing
an empty nodemask during rebind. For 3.3, I'd like to ensure that
remapping any mempolicy's nodemask will never result in an empty nodemask.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2011-11-18 23:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-16 21:08 [patch " David Rientjes
2011-11-17 8:29 ` Miao Xie
2011-11-17 21:33 ` David Rientjes
2011-11-18 9:52 ` Miao Xie
2011-11-18 23:49 ` David Rientjes
2011-11-23 2:51 ` Miao Xie
2011-11-23 3:32 ` David Rientjes
2011-11-23 4:48 ` Miao Xie
2011-11-23 6:25 ` David Rientjes
2011-11-23 7:49 ` Miao Xie
2011-11-23 22:26 ` David Rientjes
2011-11-24 1:26 ` Miao Xie
2011-11-24 1:52 ` David Rientjes
2011-11-24 2:50 ` Miao Xie
2011-11-17 22:22 ` Andrew Morton
2011-11-17 23:08 ` [patch v2 " David Rientjes
2011-11-18 0:00 ` Andrew Morton
2011-11-18 23:53 ` David Rientjes [this message]
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=alpine.DEB.2.00.1111181549460.24487@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=miaox@cn.fujitsu.com \
--cc=paul@paulmenage.org \
--cc=torvalds@linux-foundation.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