I think there's a mixup in the flag name there, but I actually would
recommend against any flag to effect Choice A. It's simply going to be
too complex to describe and is going to be a headache to code and support.
The MPOL_PREFERRED behavior when constrained by cpusets was previously, to
my knowledge, undocumented; you're in the position to make the behavior do
what you want it to do and then release documentation so we'll finally
have a complete and unambiguous API for it. Right now it should be
considered undefined and thus you are free to implement it as you choose.
Then all callers of set_mempolicy(MPOL_PREFERRED) will standardize on that
and not have to worry about the machine's
mpol_preferred_relative_to_cpuset setting.
Then, any task that is attached to a cpuset and expecting the fourth node
in their set_mempolicy(MPOL_PREFERRED) call to mean system node 3 if
it's in the cpuset's mems_allowed will be broken. If you want that,
you'll need your task to be attached to a cpuset with at least mems 0-3;
programmers will pick that up quickly enough if it's clearly documented.
I think Choice B is correct and makes more sense in terms of the semantics
and at least allows mempolicies and cpusets to play nicely together
without a bidirectional dependency on one another.
David
-
