On Thu, 17 Nov 2011 15:08:08 -0800 (PST)
David Rientjes <rientjes@xxxxxxxxxx> wrote:
> cpusets: stall when updating mems_allowed for mempolicy or disjoint nodemask
>
> c0ff7453bb5c ("cpuset,mm: fix no node to alloc memory when changing
> cpuset's mems") adds get_mems_allowed() to prevent the set of allowed
> nodes from changing for a thread. This causes any update to a set of
> allowed nodes to stall until put_mems_allowed() is called.
>
> This stall is unncessary, however, if at least one node remains unchanged
> in the update to the set of allowed nodes. This was addressed by
> 89e8a244b97e ("cpusets: avoid looping when storing to mems_allowed if one
> node remains set"), but it's still possible that an empty nodemask may be
> read from a mempolicy because the old nodemask may be remapped to the new
> nodemask during rebind. To prevent this, only avoid the stall if there
> is no mempolicy for the thread being changed.
>
> This is a temporary solution until all reads from mempolicy nodemasks can
> be guaranteed to not be empty without the get_mems_allowed()
> synchronization.
>
> Also moves the check for nodemask intersection inside task_lock() so that
> tsk->mems_allowed cannot change. This ensures that nothing can set this
> tsk's mems_allowed out from under us and also protects tsk->mempolicy.
Nothing in this changelog makes me understand why you think we need this
change in 3.2. What are the user-visible effects of this change?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>