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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
