Hi Lee, On Thu, Aug 7, 2008 at 6:13 PM, Lee Schermerhorn <Lee.Schermerhorn@xxxxxx> wrote: > 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. Okay -- I applied this patch for man-pages-3.07, and changed "task" to "process". Thanks, Michael >> > +[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. >> > >> > > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html -- 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
