Re: 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 <richard-li8END47hbdWk0Htik3J/w@public.gmane.org>]

Michal Hocko wrote:
> Richard Davies wrote:
> > Dwight Engen wrote:
> > > Is there a plan to separately account/limit stack pages vs kmem in
> > > general? Richard would have to verify, but I suspect kmem is not
> > > currently viable as a process limiter for him because
> > > icache/dcache/stack is all accounted together.
> >
> > Certainly I would like to be able to limit container fork-bombs without
> > limiting the amount of disk IO caching for processes in those containers.
> >
> > In my testing with of kmem limits, I needed a limit of 256MB or lower to
> > catch fork bombs early enough. I would definitely like more than 256MB of
> > disk caching.
> >
> > So if we go the "working kmem" route, I would like to be able to specify a
> > limit excluding disk cache.
>
> Page cache (which is what you mean by disk cache probably) is a
> userspace accounted memory with the memory cgroup controller. And you
> do not have to limit that one.

OK, that's helpful - thanks.

As an aside, with the normal (non-kmem) cgroup controller, is there a way
for me to exclude page cache and only limit the equivalent of the rss line
in memory.stat?

e.g. say I have a 256GB physical machine, running 200 containers, each with
1GB normal-mem limit (for running software) and 256MB kmem limit (to stop
fork-bombs).

The physical disk IO bandwidth is a shared resource between all the
containers, so ideally I would like the kernel to used the 56GB of RAM as
shared page cache however it best reduces physical IOPs, rather than having
a per-container limit.

Thanks,

Richard.