linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>,
	Tim Hockin <thockin@google.com>
Cc: Michal Hocko <mhocko@suse.cz>,
	Serge Hallyn <serge.hallyn@ubuntu.com>,
	Richard Davies <richard@arachsys.com>,
	Vladimir Davydov <vdavydov@parallels.com>,
	Marian Marinov <mm@yuhu.biz>, Max Kellermann <mk@cm4all.com>,
	Tim Hockin <thockin@hockin.org>,
	containers@lists.linux-foundation.org, cgroups@vger.kernel.org,
	Glauber Costa <glommer@parallels.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	William Dauchy <wdauchy@gmail.com>,
	Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>,
	David Rientjes <rientjes@google.com>
Subject: Re: Protection against container fork bombs [WAS: Re: memcg with kmem limit doesn't recover after disk i/o causes limit to be hit]
Date: Wed, 30 Apr 2014 09:12:20 -0400	[thread overview]
Message-ID: <5360F6B4.9010308@redhat.com> (raw)
In-Reply-To: <20140429214454.GF6129@localhost.localdomain>


On 04/29/2014 05:44 PM, Frederic Weisbecker wrote:
> On Tue, Apr 29, 2014 at 09:59:30AM -0700, Tim Hockin wrote:
>> Here's the reason it doesn't work for us: It doesn't work.  It was
>> something like 2 YEARS since we first wanted this, and it STILL does
>> not work.
> When I was working on the task counter cgroup subsystem 2 years
> ago, the patches were actually pushed back by google people, in favour
> of task stack kmem cgroup subsystem.
>
> The reason was that expressing the forkbomb issue in terms of
> number of tasks as a resource is awkward and that the real resource
> in the game comes from kernel memory exhaustion due to task stack being
> allocated over and over, swap ping-pong and stuffs...
>
> And that was a pretty good argument. I still agree with that. Especially
> since that could solve others people issues at the same time. kmem
> cgroup has a quite large domain of application.
>
>> You're postponing a pretty simple request indefinitely in
>> favor of a much more complex feature, which still doesn't really give
>> me what I want.  What I want is an API that works like rlimit but
>> per-cgroup, rather than per-UID.
> The request is simple but I don't think that adding the task counter
> cgroup subsystem is simpler than extending the kmem code to apply limits
> to only task stack. Especially in terms of maintainance.
>
> Also you guys have very good mm kernel developers who are already
> familiar with this.
I would look at this from a Usability point of view.  It is a lot easier
to understand number of processes then the mount of KMEM those processes
will need.  Setting something like
ProcessLimit=1000 in a systemd unit file is easy to explain.  Now if
systemd has the ability to translate this into something that makes
sense in terms of kmem cgroup, then my argument goes away.

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

  reply	other threads:[~2014-04-30 13:12 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-16 15:46 memcg with kmem limit doesn't recover after disk i/o causes limit to be hit Richard Davies
2014-04-18 15:59 ` Michal Hocko
2014-04-18 17:57   ` Vladimir Davydov
2014-04-18 18:20     ` Michal Hocko
2014-04-18 18:37       ` Vladimir Davydov
2014-04-20 14:28     ` Protection against container fork bombs [WAS: Re: memcg with kmem limit doesn't recover after disk i/o causes limit to be hit] Richard Davies
2014-04-20 18:35       ` Tim Hockin
2014-04-22 18:39       ` Dwight Engen
2014-04-22 20:05         ` Richard Davies
2014-04-22 20:13           ` Tim Hockin
2014-04-23  6:07           ` Marian Marinov
2014-04-23 12:49             ` Dwight Engen
2014-04-28 18:00               ` Serge Hallyn
2014-04-29  7:25                 ` Michal Hocko
2014-04-29 13:03                   ` Serge Hallyn
2014-04-29 13:57                     ` Marian Marinov
2014-04-29 14:04                     ` Tim Hockin
2014-04-29 15:43                     ` Michal Hocko
2014-04-29 16:06                       ` Tim Hockin
2014-04-29 16:51                         ` Frederic Weisbecker
2014-04-29 16:59                           ` Tim Hockin
2014-04-29 17:06                             ` Michal Hocko
2014-04-29 17:30                               ` Dwight Engen
2014-04-29 18:09                                 ` Richard Davies
2014-04-29 18:27                                   ` Michal Hocko
2014-04-29 18:39                                     ` Richard Davies
2014-04-29 19:03                                       ` Michal Hocko
2014-04-29 21:36                                     ` Marian Marinov
2014-04-30 13:31                                       ` Michal Hocko
2014-04-29 21:44                             ` Frederic Weisbecker
2014-04-30 13:12                               ` Daniel J Walsh [this message]
2014-04-30 13:28                                 ` Frederic Weisbecker
2014-05-06 11:40               ` Marian Marinov
2014-05-07 17:15                 ` Dwight Engen
2014-05-07 22:39                   ` Marian Marinov
2014-05-08 15:25                     ` Richard Davies
2014-06-10 14:50               ` Marian Marinov
2014-06-10 12:18           ` Alin Dobre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5360F6B4.9010308@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=glommer@parallels.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=mk@cm4all.com \
    --cc=mm@yuhu.biz \
    --cc=richard@arachsys.com \
    --cc=rientjes@google.com \
    --cc=serge.hallyn@ubuntu.com \
    --cc=thockin@google.com \
    --cc=thockin@hockin.org \
    --cc=tj@kernel.org \
    --cc=vdavydov@parallels.com \
    --cc=wdauchy@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).