On Thu, 2008-08-07 at 15:35 +0200, Michael Kerrisk wrote: > Lee, > > I'll make the required changes to the patch below, if you can just Ack / > clarify them. > > Lee Schermerhorn wrote: > > Add discussion of mempolicy mode flags to set_mempolicy(2). > > > > This adds another reason for EINVAL. > > > > Signed-off-by: Lee Schermerhorn <lee.schermerhorn@xxxxxx> > > > > man2/set_mempolicy.2 | 48 +++++++++++++++++++++++++++++++++++++++++++++++- > > 1 files changed, 47 insertions(+), 1 deletion(-) > > > > Index: man-pages-3.05/man2/set_mempolicy.2 > > =================================================================== > > --- man-pages-3.05.orig/man2/set_mempolicy.2 2008-07-29 16:46:45.000000000 -0400 > > +++ man-pages-3.05/man2/set_mempolicy.2 2008-07-29 16:49:32.000000000 -0400 > > @@ -85,6 +85,30 @@ require the caller to specify via the > > .I nodemask > > argument one or more nodes. > > > > +The > > +.I mode > > +argument may also include an optional > > +.IR "mode flag ". > > +The supported > > +.I "mode flags" > > +are: > > +.TP > > +.B MPOL_F_STATIC_NODES > > We need a version number here. Looks like it's 2.6.26, right? Yes, looks like it. > > > +A non-empty > > +.I nodemask > > +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 > > s/task/thread/ ? > (Userland programmers don't know about "tasks".) > > > +current cpuset context changes. > > +.TP > > +.B MPOL_F_RELATIVE_NODES > > We need a version number here. Looks like it's 2.6.26, right? Yes, they went in at the same time. > > > +A non-empty > > +.I nodemask > > +specifies node ids that are relative to the set of > > +node ids allowed by the task's current cpuset. > > s/task/thread/ ? Hmm, well I guess that internally, the cpuset context is associated with the task [~= "thread"] structure. I've never tried to move a single thread of a task/process to a different cpuset, but it's doable. I think I'd prefer to see "process" over "thread", and maybe add a NOTE to the effect that cpusets could be set per thread, but that this is not common usage [I think]. However, the cpuset man page does talk in terms of threads. > > > +.PP > > .I nodemask > > points to a bit mask of node IDs that contains up to > > .I maxnode > > @@ -104,11 +128,27 @@ is zero, > > the > > .I nodemask > > argument is ignored. > > + > > Where a > > .I nodemask > > is required, it must contain at least one node that is on-line, > > -allowed by the process' current cpuset context, > > +allowed by the task's current cpuset context > > s/task/thread/ ? See above. > > > +[unless the > > +.B MPOL_F_STATIC_NODES > > +mode flag is specified], > > and contains memory. > > +If the > > +.B MPOL_F_STATIC_NODES > > +is set in > > +.I mode > > +and a required > > +.I nodemask > > +contains no nodes that are allowed by the process' current cpuset context, > > +the memory policy reverts to > > +.IR "local allocation" . > > +This effectively overrides the specified policy until the process' > > +cpuset context includes one or more of the nodes specified by > > +.IR nodemask. > > > > The > > .B MPOL_DEFAULT > > @@ -219,6 +259,12 @@ Or, none of the node IDs specified by > > .I nodemask > > are on-line and allowed by the process' current cpuset context, > > or none of the specified nodes contain memory. > > +Or, the > > +.I mode > > +argument specified both > > +.B MPOL_F_STATIC_NODES > > +and > > +.BR MPOL_F_RELATIVE_NODES . > > .TP > > .B ENOMEM > > Insufficient kernel memory was available. > > > -- 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
