From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>,
LKML <linux-kernel@vger.kernel.org>,
kiran@scalex86.org, cl@linux-foundation.org, mel@csn.ul.ie,
stable@kernel.org, linux-mm <linux-mm@kvack.org>,
akpm@linux-foundation.org
Subject: Re: [PATCH 3/5] tmpfs: handle MPOL_LOCAL mount option properly
Date: Wed, 17 Mar 2010 21:55:38 -0400 [thread overview]
Message-ID: <1268877338.4773.151.camel@useless.americas.hpqcorp.net> (raw)
In-Reply-To: <20100318084915.8723.A69D9226@jp.fujitsu.com>
On Thu, 2010-03-18 at 08:52 +0900, KOSAKI Motohiro wrote:
> > On Tue, 16 Mar 2010, KOSAKI Motohiro wrote:
> >
> > > commit 71fe804b6d5 (mempolicy: use struct mempolicy pointer in
> > > shmem_sb_info) added mpol=local mount option. but its feature is
> > > broken since it was born. because such code always return 1 (i.e.
> > > mount failure).
> > >
> > > This patch fixes it.
> > >
> > > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > > Cc: Ravikiran Thirumalai <kiran@scalex86.org>
> >
> > Thank you both for finding and fixing these mpol embarrassments.
> >
> > But if this "mpol=local" feature was never documented (not even in the
> > commit log), has been broken since birth 20 months ago, and nobody has
> > noticed: wouldn't it be better to save a little bloat and just rip it out?
>
> I have no objection if lee agreed, lee?
> Of cource, if we agree it, we can make the new patch soon :)
>
Well, given the other issues with mpol_parse_str(), I suspect the entire
tmpfs mpol option is not used all that often in the mainline kernel. I
recall that this feature was introduced by SGI for some of their
customers who may depend on it. There have been cases where I could
have used it were it supported for the SYSV shm and MAP_ANON_MAP_SHARED
internal tmpfs mount. Further, note that the addition of "mpol=local"
occurred between when the major "enterprise distributions" selected a
new mainline kernel. Production users of those distros, who are the
likely users of this feature, tend not to live on the bleeding edge.
So, maybe we shouldn't read too much into it not being discovered until
now.
That being said, I suppose I wouldn't be all that opposed to deprecating
the entire tmpfs mpol option, and see who yells. If the mpol mount
options stays, I'd like to see the 'local' option stay. It's a
legitimate behavior that one can specify via the system calls and see
via numa_maps, so I think the mpol mount option, if it exists, should
support a way to specify it.
As for bloat, the additional code on the mount option side to support it
is:
case MPOL_LOCAL:
/*
* Don't allow a nodelist; mpol_new() checks flags
*/
if (nodelist)
goto out;
mode = MPOL_PREFERRED;
break;
Lee
--
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:[~2010-03-18 1:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201003122353.o2CNrC56015250@imap1.linux-foundation.org>
2010-03-16 5:47 ` + tmpfs-fix-oops-on-remounts-with-mpol=default.patch added to -mm tree KOSAKI Motohiro
2010-03-16 5:49 ` [PATCH 1/5] tmpfs: fix oops on mounts with mpol=default KOSAKI Motohiro
2010-03-17 14:16 ` Lee Schermerhorn
2010-03-16 5:50 ` [PATCH 2/5] tmpfs: mpol=bind:0 don't cause mount error KOSAKI Motohiro
2010-03-17 14:17 ` Lee Schermerhorn
2010-03-16 5:51 ` [PATCH 3/5] tmpfs: handle MPOL_LOCAL mount option properly KOSAKI Motohiro
2010-03-17 14:25 ` Lee Schermerhorn
2010-03-17 16:26 ` Hugh Dickins
2010-03-17 23:52 ` KOSAKI Motohiro
2010-03-18 1:55 ` Lee Schermerhorn [this message]
2010-03-18 21:21 ` Hugh Dickins
2010-03-16 5:52 ` [PATCH 4/5] tmpfs: cleanup mpol_parse_str() KOSAKI Motohiro
2010-03-17 14:25 ` Lee Schermerhorn
2010-03-16 5:53 ` [PATCH 5/5] doc: add the documentation for mpol=local KOSAKI Motohiro
2010-03-17 14:42 ` 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=1268877338.4773.151.camel@useless.americas.hpqcorp.net \
--to=lee.schermerhorn@hp.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=hugh.dickins@tiscali.co.uk \
--cc=kiran@scalex86.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=stable@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