Re: [RFC][PATCH] Clarify mem_cgroup lock handling and avoid races.

[Balbir Singh <balbir@linux.vnet.ibm.com>]

KAMEZAWA Hiroyuki wrote:
> On Wed, 20 Feb 2008 16:25:00 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
>> Paul Menage wrote:
>>> On Feb 20, 2008 2:11 AM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>>>> Dynamically turning on/off the memory controller, can/will lead to accounting
>>>> issues and deficiencies, since the memory controller would now have no idea of
>>>> how much memory has been allocated by which cgroup.
>>>>
>>> A cgroups subsystem can only be unbound from its hierarchy when there
>>> are no child cgroups of the root cgroup in that hierarchy. So this
>>> shouldn't be too much of a problem - when this transition occurs, all
>>> tasks are in the same group, and no other groups exist.
>>>
>>> Paul
>> Yes, I agree, but then at the point of unbinding them, tasks could have already
>> allocated several pages to their RSS or brought in pages into the page cache.
>> Accounting from this state is not so straight forward and will lead to more
>> complexity in code.
> 
> unbind -> force_empty can't work ?
> 
> Thanks,
> -Kame
> 

Kame, unbind->force_empty can work, but we can't force_empty the root cgroup.
Even if we could, the code to deal with turning on/off the entire memory
controller and accounting is likely to be very complex and probably racy.

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>