From: David Rientjes <rientjes@google.com>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Paul Jackson <pj@sgi.com>, Christoph Lameter <clameter@sgi.com>,
Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org, linux-mm <linux-mm@kvack.org>,
Eric Whitney <eric.whitney@hp.com>
Subject: Re: Regression: Re: [patch -mm 2/4] mempolicy: create mempolicy_operations structure
Date: Fri, 7 Mar 2008 13:48:59 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.1.00.0803071341090.26765@chino.kir.corp.google.com> (raw)
In-Reply-To: <1204922646.5340.73.camel@localhost>
On Fri, 7 Mar 2008, Lee Schermerhorn wrote:
> It also appears that the patch series listed above required a non-empty
> nodemask with MPOL_DEFAULT. However, I didn't test that. With this
> patch, MPOL_DEFAULT effectively ignores the nodemask--empty or not.
> This is a change in behavior that I have argued against, but the
> regression tests don't test this, so I'm not going to attempt to address
> it with this patch.
>
Excuse me, but there was significant discussion about this on LKML and I
eventually did force MPOL_DEFAULT to require a non-empty nodemask
specifically because of your demand that it should. It didn't originally
require this in my patchset, and now you're removing the exact same
requirement that you demanded.
You said on February 13:
1) we've discussed the issue of returning EINVAL for non-empty
nodemasks with MPOL_DEFAULT. By removing this restriction, we run
the risk of breaking applications if we should ever want to define
a semantic to non-empty node mask for MPOL_DEFAULT.
If you want to remove this requirement now (please get agreement from
Paul) and are sure of your position, you'll at least need an update to
Documentation/vm/numa-memory-policy.txt.
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-03-07 21:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.DEB.1.00.0803061135001.18590@chino.kir.corp.google.com>
[not found] ` <alpine.DEB.1.00.0803061135560.18590@chino.kir.corp.google.com>
2008-03-07 20:44 ` Lee Schermerhorn
2008-03-07 21:48 ` David Rientjes [this message]
2008-03-07 21:57 ` Paul Jackson
2008-03-08 18:49 ` Lee Schermerhorn
2008-03-08 22:09 ` David Rientjes
2008-03-10 14:58 ` Lee Schermerhorn
2008-03-12 19:33 ` [PATCH] Mempolicy: fix parsing of tmpfs mpol mount option Lee Schermerhorn
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.1.00.0803071341090.26765@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=Lee.Schermerhorn@hp.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=eric.whitney@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pj@sgi.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