> 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.
Yes
> All policies are effected on a contextualized per-allocation
> basis.
"contextualized" - I guess that means converted to cpuset
relative numbering - yes.
"per-allocation" - Most of the calculation of nodemasks and
zonelists is done when memory policies change.
> Policies such as MPOL_INTERLEAVE always get AND'd with
> pol->cpuset_mems_allowed.
Not AND'd - Folded, as in bitmap_remap().
> If that yields numa_no_nodes, MPOL_DEFAULT is used instead.
Not an issue with Folding.
> Policies such as MPOL_PREFERRED are respected if the node
> is set in pol->cpuset_mems_allowed, otherwise MPOL_DEFAULT
> is used.
Not an issue with Folding.
> 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.
Not issues with Folding.
> 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.
Not issues with Folding.
With folding, an application that layed out an elaborate memory
policy configuration covering say 16 nodes can run in a 4 node
cpuset, where whatever would have been on node N gets folded down
to node N % 4.
With AND'ing, such an application would find 3/4's of its fancy
memory policy configuration replaced with MPOL_DEFAULT and -EINVAL
fallbacks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
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/
