LKML Archive on
help / color / mirror / Atom feed
From: Lee Schermerhorn <>
To: David Rientjes <>
Cc: Andrew Morton <>,
	Paul Jackson <>, Christoph Lameter <>,
	Andi Kleen <>,, linux-mm <>,
	Eric Whitney <>
Subject: Re: Regression:  Re: [patch -mm 2/4] mempolicy: create mempolicy_operations structure
Date: Mon, 10 Mar 2008 10:58:48 -0400	[thread overview]
Message-ID: <1205161128.5579.16.camel@localhost> (raw)
In-Reply-To: <>

On Sat, 2008-03-08 at 14:09 -0800, David Rientjes wrote: 
> On Sat, 8 Mar 2008, Lee Schermerhorn wrote:
> > > Excuse me, but there was significant discussion about this on LKML and I 
> > > eventually did force MPOL_DEFAULT to require a non-empty nodemask 
> Correction: s/non-empty/empty

That makes more sense.  I agree.  more below... 
> > > 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.
> > 
> > Excuse me.  I thought that the discussion--my position, anyway--was
> > about preserving existing behavior for MPOL_DEFAULT which is to require
> > an EMPTY [or NULL--same effect] nodemask.  Not a NON-EMPTY one.  See:
> >
> > It does appear that your patches now require a non-empty nodemask.  This
> > was intentional?
> > 
> The first and second set did not have this requirement, but the third set 
> does (not currently in -mm), so I've changed it back.  Hopefully there's 
> no confusion and we can settle on a solution without continuously 
> revisiting the topic.
> My position was originally to allow any type of nodemask to be passed with 
> MPOL_DEFAULT since its not used.  You asked for strict argument checking 
> and so after some debate I changed it to require an empty nodemask mainly 
> because I didn't want the patchset to stall on such a minor point.  But in 
> your regression fix, you expressed the desire once again to allow it to 
> accept any nodemask because the testsuite does not check for it.

Not a desire.  Just that when I fixed the MPOL_PREFERRED with empty node
mask regression, I also fixed mpol_new() not to require a non-empty
nodemask with MPOL_DEFAULT.  I didn't go the extra step to require an
empty one.  I'm tiring of the subject, as I think you are, and didn't
want to argue it anymore.  So, I was willing to "cave" on that point.

> So if you'd like to do that, I'd encourage you to submit it as a separate 
> patch and open it up for review.

No, I'm quite happy if, after your patches, the APIs retain the previous
behavior w/rt nodemask error checking.

> What is currently in -mm and what I will be posting shortly is the updated 
> regression fix.  All of these patches require that MPOL_DEFAULT include a 
> NULL pointer or empty nodemask passed via the two syscalls.
> > Note:  in the subject patch, I didn't enforce this behavior because your
> > patch didn't [it enforced just the opposite], and I've pretty much given
> > up.  Although I prefer current behavior [before your series], if we
> > change it, we will need to change the man pages to remove the error
> > condition for non-empty nodemasks with MPOL_DEFAULT.
> > 
> With my patches it still requires a NULL pointer or empty nodemask and 
> I've updated Documentation/vm/numa_memory_policy.txt to explicitly say its 
> an error if a non-empty nodemask is passed.


Do you intend for your patch entitled "[patch -mm v2] mempolicy:
disallow static or relative flags for local preferred mode" to replace
the patch that I sent in to repair the regression?  Looks that way.
I'll replace it in my tree and retest.


  reply	other threads:[~2008-03-10 14:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-06 20:05 [patch -mm 1/4] mempolicy: move rebind functions David Rientjes
2008-03-06 20:05 ` [patch -mm 2/4] mempolicy: create mempolicy_operations structure David Rientjes
2008-03-06 20:05   ` [patch -mm 3/4] mempolicy: small header file cleanup David Rientjes
2008-03-06 20:05     ` [patch -mm 4/4] mempolicy: remove includes for duplicate headers David Rientjes
2008-03-06 20:19       ` Paul Jackson
2008-03-06 20:51         ` David Rientjes
2008-03-06 21:01           ` Paul Jackson
2008-03-07  8:45             ` Andrew Morton
2008-03-07 20:44   ` Regression: Re: [patch -mm 2/4] mempolicy: create mempolicy_operations structure Lee Schermerhorn
2008-03-07 21:48     ` David Rientjes
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 [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1205161128.5579.16.camel@localhost \ \ \ \ \ \ \ \ \ \
    --subject='Re: Regression:  Re: [patch -mm 2/4] mempolicy: create mempolicy_operations structure' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).