Messages in this thread | | | Subject | Re: Regression: Re: [patch -mm 2/4] mempolicy: create mempolicy_operations structure | From | Lee Schermerhorn <> | Date | Mon, 10 Mar 2008 10:58:48 -0400 |
| |
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: > > http://www.kernel.org/doc/man-pages/online/pages/man2/set_mempolicy.2.html > > 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.
Good.
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.
Lee
| |