Re: [patch 2/2] cpusets: add interleave_over_allowed option

David Rientjes
2007-10-29T07:00:53Z

On Sun, 28 Oct 2007, Paul Jackson wrote:

> > If we can't identify any applications that would be broken by this, what's
> > the difference in simply implementing Choice B and then, if we hear
> > complaints, add your hack to revert back to Choice A behavior based on the
> > get_mempolicy() call you specified is always part of libnuma?
>
> I'll probably reply to other parts of your message later, but this
> one catches my eye right now.
>
> "if we hear complaints, add your hack ... back" -- this doesn't seem
> like a good idea to me. Maybe inside Google you don't see it, but
> for those of us shipping computer systems using major distributions
> such as SUSE or Red Hat, there can be a year lag between when I send a
> feature patch to Andrew, and when my customers send their first
> feedback to me resulting from using that new feature.
>

Let's add a Choice C:

Any nodemask that is passed to set_mempolicy() is saved as the
intent of the application in struct mempolicy. All policies
are effected on a contextualized per-allocation basis.

Policies such as MPOL_INTERLEAVE always get AND'd with
pol->cpuset_mems_allowed. If that yields numa_no_nodes,
MPOL_DEFAULT is used instead.

Policies such as MPOL_PREFERRED are respected if the node is set
in pol->cpuset_mems_allowed, otherwise MPOL_DEFAULT is used.

If an application attempts to setup a memory policy for an
MPOL_PREFERRED node that it doesn't have access to or an
MPOL_INTERLEAVE nodemask that is empty when AND'd with
pol->cpuset_mems_allowed, -EINVAL is returned and no new policy
is effected.

If an application gains nodes in pol->cpuset_mems_allowed that
now include the nodes from MPOL_INTERLEAVE or MPOL_PREFERRED,
that policy is then effected once again. Otherwise,
MPOL_DEFAULT is still used.