Yes, when a task with MPOL_INTERLEAVE has its cpuset mems_allowed expanded
to include more memory. The task itself can't access all that memory with
the memory policy of its choice.
Since the cpuset has changed the mems_allowed of the task without its
knowledge, it would require a constant get_mempolicy() and set_mempolicy()
loop in the application to catch these changes. That's obviously not in
the best interest of anyone.
So my change allows those tasks that have already expressed the desire to
interleave their memory with MPOL_INTERLEAVE to always use the full range
of memory available that is dynamically changing beneath them as a result
of cpusets. Keep in mind that it is still possible to request an
interleave only over a subset of allowed mems: but you must do it when you
create the interleaved mempolicy after it has been attached to the cpuset.
set_mempolicy() changes are always honored.
The only other way to support such a feature is through a modification to
mempolicies themselves, which Lee has already proposed. The problem with
that is it requires mempolicy support for cpuset cases and modification to
the set_mempolicy() API. My solution presents a cpuset fix for a cpuset
problem.
I find it hard to believe that a single cpuset with a single
memory_spread_user boolean is going to include multiple tasks that request
interleaved mempolicies over differing nodes within the cpuset's
mems_allowed. That, to me, is the special case.
David
-
