From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: kosaki.motohiro@jp.fujitsu.com,
Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH 2.6.24-mm1] Mempolicy: silently restrict nodemask to allowed nodes V3
Date: Tue, 12 Feb 2008 10:56:56 +0900 [thread overview]
Message-ID: <20080212103944.29A9.KOSAKI.MOTOHIRO@jp.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.1.00.0802111649330.6119@chino.kir.corp.google.com>
Hi
> > # remove almost CC'd
>
> Please don't remove cc's that were included on the original posting if
> you're passing the patch along.
Oops, sorry.
I was not worth of solicitude.
> > OK.
> > I append my Tested-by.(but not Singed-off-by because my work is very little).
> >
> > and, I attached .24 adjusted patch.
> > my change is only line number change and remove extra space.
>
> Andrew may clarify this, but I believe you need to include a sign-off line
> even if you alter just that one whitespace.
>
> [ I edited that whitespace in my own copy of this patch when I applied it
> to my tree because git complained about it (and my patchset removes the
> same line with the whitespace removed). ]
Hmm..
OK
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > I'm still deferring David Rientjes' suggestion to fold
> > mpol_check_policy() into mpol_new(). We need to sort out whether
> > mempolicies specified for tmpfs and hugetlbfs mounts always need the
> > same "contextualization" as user/application installed policies. I
> > don't want to hold up this bug fix for that discussion. This is
> > something Paul J will need to address with his cpuset/mempolicy rework,
> > so we can sort it out in that context.
> >
>
> I took care of this in my patchset from this morning, so I think we can
> drop this disclaimer now.
Disagreed.
this patch is regression fixed patch.
regression should fixed ASAP.
your patch is very nice patch.
but it is feature enhancement.
the feature enhancement should tested by many people in -mm tree for a while.
end up, timing of mainline merge is large different.
> > 2) In existing mpol_check_policy() logic, after "contextualization":
> > a) MPOL_DEFAULT: require that in coming mask "was_empty"
>
> While my patchset effectively obsoletes this patch (but is nonetheless
> based on top of it), I don't understand why you require that MPOL_DEFAULT
> nodemasks are empty.
>
> mpol_new() will not dynamically allocate a new mempolicy in that case
> anyway since it is the system default so the only reason why
> set_mempolicy(MPOL_DEFAULT, numa_no_nodes, ...) won't work is because of
> this addition to mpol_check_policy().
>
> In other words, what is the influence to dismiss a MPOL_DEFAULT mempolicy
> request from a user as invalid simply because it includes set nodes in the
> nodemask?
Hmm..
By which version are you testing?
my testing result was
set_mempolicy(MPOL_DEFAULT,NULL) set_mempolicy(MPOL_DEFAULT,numa_no_nodes)
------------------------------------------------------------------------------
2.6.24 success success
2.6.24 + lee-patch success success
--
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-02-12 1:56 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-02 8:12 [2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't works on memoryless node KOSAKI Motohiro
2008-02-02 9:09 ` Andi Kleen
2008-02-02 9:37 ` KOSAKI Motohiro
2008-02-02 11:30 ` Andi Kleen
2008-02-04 19:03 ` Christoph Lameter
2008-02-04 18:20 ` Lee Schermerhorn
2008-02-05 9:26 ` [2.6.24 regression][BUGFIX] " KOSAKI Motohiro
2008-02-08 19:45 ` [PATCH 2.6.24-mm1] Mempolicy: silently restrict nodemask to allowed nodes V3 Lee Schermerhorn
2008-02-09 18:11 ` KOSAKI Motohiro
2008-02-10 5:29 ` KOSAKI Motohiro
2008-02-10 5:49 ` Greg KH
2008-02-10 7:42 ` Linus Torvalds
2008-02-10 10:31 ` Andrew Morton
2008-02-11 16:47 ` Lee Schermerhorn
2008-02-12 0:43 ` KOSAKI Motohiro
2008-02-12 1:00 ` David Rientjes
2008-02-12 1:56 ` KOSAKI Motohiro [this message]
2008-02-12 2:05 ` David Rientjes
2008-02-12 3:05 ` KOSAKI Motohiro
2008-02-12 3:17 ` David Rientjes
2008-02-12 15:08 ` Lee Schermerhorn
2008-02-12 19:06 ` David Rientjes
2008-02-13 0:07 ` Lee Schermerhorn
2008-02-13 0:42 ` David Rientjes
2008-02-13 16:32 ` Lee Schermerhorn
2008-02-13 18:32 ` David Rientjes
2008-02-13 18:56 ` Lee Schermerhorn
2008-02-12 4:30 ` [PATCH for 2.6.24][regression fix] " KOSAKI Motohiro
2008-02-12 5:06 ` David Rientjes
2008-02-12 5:07 ` Andrew Morton
2008-02-12 13:18 ` KOSAKI Motohiro
2008-02-05 10:17 ` [2.6.24-rc8-mm1][regression?] numactl --interleave=all doesn't works on memoryless node Paul Jackson
2008-02-05 11:14 ` KOSAKI Motohiro
2008-02-05 19:56 ` David Rientjes
2008-02-05 20:51 ` Paul Jackson
2008-02-05 21:03 ` David Rientjes
2008-02-05 21:33 ` Paul Jackson
2008-02-05 22:04 ` Lee Schermerhorn
2008-02-05 22:44 ` David Rientjes
2008-02-05 22:50 ` Paul Jackson
2008-02-05 14:31 ` Mel Gorman
2008-02-05 15:23 ` Lee Schermerhorn
2008-02-05 18:12 ` Christoph Lameter
2008-02-05 18:27 ` Lee Schermerhorn
2008-02-05 19:04 ` Christoph Lameter
2008-02-05 19:15 ` Paul Jackson
2008-02-05 20:06 ` 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=20080212103944.29A9.KOSAKI.MOTOHIRO@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=Lee.Schermerhorn@hp.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.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