On 2016/5/5 16:32, Michal Hocko wrote:
> On Thu 05-05-16 16:15:01, Qiang Huang wrote:
>> We don't have this restriction for a long time, docs should
>> be fixed.
>>
>> Signed-off-by: Qiang Huang <h.huangqi...@huawei.com>
>> ---
>>  Documentation/cgroup-v1/memory.txt | 8 +++-----
>>  1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/cgroup-v1/memory.txt 
>> b/Documentation/cgroup-v1/memory.txt
>> index ff71e16..d45b201 100644
>> --- a/Documentation/cgroup-v1/memory.txt
>> +++ b/Documentation/cgroup-v1/memory.txt
>> @@ -281,11 +281,9 @@ different than user memory, since it can't be swapped 
>> out, which makes it
>>  possible to DoS the system by consuming too much of this precious resource.
>>  
>>  Kernel memory won't be accounted at all until limit on a group is set. This
>> -allows for existing setups to continue working without disruption.  The 
>> limit
>> -cannot be set if the cgroup have children, or if there are already tasks in 
>> the
>> -cgroup. Attempting to set the limit under those conditions will return 
>> -EBUSY.
>> -When use_hierarchy == 1 and a group is accounted, its children will
>> -automatically be accounted regardless of their limit value.
>> +allows for existing setups to continue working without disruption. When
>> +use_hierarchy == 1 and a group is accounted, its children will automatically
>> +be accounted regardless of their limit value.
> The restriction is not there anymore because the accounting is enabled
> by default even in the cgroup v1 - see b313aeee2509 ("mm: memcontrol:
> enable kmem accounting for all cgroups in the legacy hierarchy"). So
> this _whole_ paragraph could see some update.

Sorry for the delay.
Thanks for the hint, I'll sent a new patch soon.



--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to