Re: Protection against container fork bombs [WAS: Re: memcg with kmem limit doesn't recover after disk i/o causes limit to be hit]

[Marian Marinov <mm@yuhu.biz>]

On 04/29/2014 04:03 PM, Serge Hallyn wrote:
> Quoting Michal Hocko (mhocko@suse.cz):
>> On Mon 28-04-14 18:00:25, Serge Hallyn wrote:
>>> Quoting Dwight Engen (dwight.engen@oracle.com):
>>>> On Wed, 23 Apr 2014 09:07:28 +0300
>>>> Marian Marinov <mm@yuhu.biz> wrote:
>>>>
>>>>> On 04/22/2014 11:05 PM, Richard Davies wrote:
>>>>>> Dwight Engen wrote:
>>>>>>> Richard Davies wrote:
>>>>>>>> Vladimir Davydov wrote:
>>>>>>>>> In short, kmem limiting for memory cgroups is currently broken.
>>>>>>>>> Do not use it. We are working on making it usable though.
>>>>>> ...
>>>>>>>> What is the best mechanism available today, until kmem limits
>>>>>>>> mature?
>>>>>>>>
>>>>>>>> RLIMIT_NPROC exists but is per-user, not per-container.
>>>>>>>>
>>>>>>>> Perhaps there is an up-to-date task counter patchset or similar?
>>>>>>>
>>>>>>> I updated Frederic's task counter patches and included Max
>>>>>>> Kellermann's fork limiter here:
>>>>>>>
>>>>>>> http://thread.gmane.org/gmane.linux.kernel.containers/27212
>>>>>>>
>>>>>>> I can send you a more recent patchset (against 3.13.10) if you
>>>>>>> would find it useful.
>>>>>>
>>>>>> Yes please, I would be interested in that. Ideally even against
>>>>>> 3.14.1 if you have that too.
>>>>>
>>>>> Dwight, do you have these patches in any public repo?
>>>>>
>>>>> I would like to test them also.
>>>>
>>>> Hi Marian, I put the patches against 3.13.11 and 3.14.1 up at:
>>>>
>>>> git://github.com/dwengen/linux.git cpuacct-task-limit-3.13
>>>> git://github.com/dwengen/linux.git cpuacct-task-limit-3.14
>>>
>>> Thanks, Dwight.  FWIW I'm agreed with Tim, Dwight, Richard, and Marian
>>> that a task limit would be a proper cgroup extension, and specifically
>>> that approximating that with a kmem limit is not a reasonable substitute.
>>
>> The current state of the kmem limit, which is improving a lot thanks to
>> Vladimir, is not a reason for a new extension/controller. We are just
>> not yet there.
>
> It has nothing to do with the state of the limit.  I simply don't
> believe that emulating RLIMIT_NPROC by controlling stack size is a
> good idea.
>
> -serge

I think that having a limit on the number of processes allowed in a cgroup is a lot better then relaying on the kmem limit.
The problem that task-limit tries to solve is degradation of system performance caused by too many processes in a 
certain cgroup. I'm currently testing the patches with 3.12.16.

-hackman


--
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>