Re: [patch] check cpuset mems_allowed for sys_mbind

["Ken Chen" <kenchen@google.com>]

On 5/9/07, Paul Jackson <pj@sgi.com> wrote:
> Ken wrote:
> > I wonder why we don't check cpuset's mems_allowed node mask in the
> > sys_mbind() path?
>
> Looking back through the version history of mm/mempolicy.c, I see that
> we used to check the cpuset (by calling contextualize_policy), but then
> with the following patch (Christoph added to CC list above), this was
> changed.

oh, boy, never ending circle of fixing a bug by introduce another one.
 No wonder why number of kernel bugs never goes down because everyone
is running in circles.

I see Christoph's point that when two threads live in two disjoint
cpusets, they can affect each other's memory policy and cause
undesired oom behavior.

However, mbind shouldn't create discrepancy between what is allowed
and what is promised, especially with MPOL_BIND policy.  Since a
numa-aware app has already gone such a detail to request memory
placement on a specific nodemask, they fully expect memory to be
placed there for performance reason.  If kernel lies about it, we get
very unpleasant performance issue.

I suppose neither behavior is correct nor desired.  What if we "OR"
all the nodemask for all threads in a process group and use that
nodemask to check against what is being requested, is that reasonable?

- Ken

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>