On Thu, 2008-08-07 at 15:34 +0200, Michael Kerrisk wrote: > Lee, > > (Your patch numbering got a bit wonky. There were two 4's and two 6's, but > no 5 or 7.) > > Depending what you think about the comments below, it may be worth revising > this patch and resending. > > Lee Schermerhorn wrote: > > Another attempt to rationalize description of MPOL_DEFAULT. > > > > Since ~2.6.25, the system default memory policy is "local allocation". > > So -- kernel behavior changed at 2.6.25? If so, do we not need to include > some statement about before and after behavior? Actually, the behavior did not change. The implementation did. As older man pages noted, MPOL_DEFAULT seemed to have a double meaning. For task/process policy, it meant local allocation; for memory region policy, installed by mbind(), it meant "fall back to task/process" policy. Really, in both cases, it was just removing any policy for the specified "scope" [process or memory range] so that the policy would fall back to the "surrounding scope" [system or process]. Now, the only mempolicy in the kernel where MPOL_DEFAULT actually showed up in the policy field was the system default policy. As a result, we had to have a special case for MPOL_DEFAULT where ever we act on the policy. But, we have another way to specify "local" allocation, both internally and via the APIs--using MPOL_PREFERRED. We changed the system default policy to use the "explicit local" policy and removed all of the special case for MPOL_DEFAULT. So, now MPOL_DEFAULT exist only as an API mode value that means "delete the mempolicy, if any, in the specified scope so that it falls back to the surrounding scope". I explained this in the Documentation/vm/numa_memory_policy.txt doc. I didn't think it was worth explaining mempolicy scope in the man pages. > > > MPOL_DEFAULT itself is a request to remove any non-default policy and > > "fall back" to the surrounding context. Try to say that without delving > > into implementation details. > > > > Signed-off-by: Lee Schermerhorn <lee.schermerhorn@xxxxxx> > > > > man2/set_mempolicy.2 | 19 ++++++++++--------- > > 1 files changed, 10 insertions(+), 9 deletions(-) > > > > Index: man-pages-3.05/man2/set_mempolicy.2 > > =================================================================== > > --- man-pages-3.05.orig/man2/set_mempolicy.2 2008-07-29 16:49:36.000000000 -0400 > > +++ man-pages-3.05/man2/set_mempolicy.2 2008-07-29 16:50:22.000000000 -0400 > > @@ -99,15 +99,15 @@ A non-empty > > specifies physical node ids. > > Linux does will not remap the > > .I nodemask > > -when the task moves to a different cpuset context, > > -nor when the set of nodes allowed by the task's > > +when the process moves to a different cpuset context, > > +nor when the set of nodes allowed by the process' > > current cpuset context changes. > > .TP > > .B MPOL_F_RELATIVE_NODES > > A non-empty > > .I nodemask > > specifies node ids that are relative to the set of > > -node ids allowed by the task's current cpuset. > > +node ids allowed by the process' current cpuset. > > .PP > > .I nodemask > > points to a bit mask of node IDs that contains up to > > @@ -132,7 +132,7 @@ argument is ignored. > > Where a > > .I nodemask > > is required, it must contain at least one node that is on-line, > > -allowed by the task's current cpuset context > > +allowed by the process' current cpuset context > > [unless the > > .B MPOL_F_STATIC_NODES > > mode flag is specified], > > @@ -152,8 +152,10 @@ cpuset context includes one or more of t > > > > The > > .B MPOL_DEFAULT > > -mode is the default and means to allocate memory locally, > > -i.e., on the node of the CPU that triggered the allocation. > > +mode specifies that any non-default process memory policy be removed > > +and "fall back" to the system default policy. > > +The system default policy is "local allocation"-- > > +i.e., allocate memory on the node of the CPU that triggered the allocation. > > .I nodemask > > must be specified as NULL. > > If the "local node" contains no free memory, the system will > > @@ -203,9 +205,8 @@ If the > > .I nodemask > > and > > .I maxnode > > -arguments specify the empty set, then the memory is allocated on > > -the node of the CPU that triggered the allocation (like > > -.BR MPOL_DEFAULT ). > > +arguments specify the empty set, then the policy specifies > > +explicit local allocation. > > Was there a reason to lose the words " allocated on the node of the CPU that > triggered the allocation"? Are they no longer true? If they are still true, > it seems helpful to keep them (or something similar), since "explicit local > allocation" seems a little harder to understand. Well, I had defined [sort of] "local allocation" further up when discussing the behavior of MPOL_DEFAULT and the system default mempolicy. So, I thought it was redundant to keep that long phrase here. You could just drop the "explicit" and maybe add quotes around "local allocation" and even add "like the system default policy discussed above". Whatever you think works is fine with me, tho'. > > Cheers, > > Michael > > > The process memory policy is preserved across an > > .BR execve (2), > > > -- To unsubscribe from this list: send the line "unsubscribe linux-numa" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
