Re: [PATCH 4/4] memcg: always enable kmemcg on the default hierarchy

[Michal Hocko <mhocko@kernel.org>]

On Tue 01-09-15 14:51:57, Tejun Heo wrote:
> Hello,
> 
> On Tue, Sep 01, 2015 at 02:44:59PM +0200, Michal Hocko wrote:
> > The runtime overhead is not negligible and I do not see why everybody
> > should be paying that price by default. I can definitely see the reason why
> > somebody would want to enable the kmem accounting but many users will
> > probably never care because the kernel footprint would be in the noise
> > wrt. user memory.
> 
> We said the same thing about hierarchy support.  Sure, it's not the
> same but I think it's wiser to keep the architectural decisions at a
> higher level.  I don't think kmem overhead is that high but if this
> actually is a problem we'd need a per-cgroup knob anyway.

The overhead was around 4% for the basic kbuild test without ever
triggering the [k]memcg limit last time I checked. This was quite some
time ago and things might have changed since then. Even when this got
better there will still be _some_ overhead because we have to track that
memory and that is not free.

The question really is whether kmem accounting is so generally useful
that the overhead is acceptable and it is should be enabled by
default. From my POV it is a useful mitigation of untrusted users but
many loads simply do not care because they only care about a certain
level of isolation.

I might be wrong here of course but if the default should be switched it
would deserve a better justification with some numbers so that people
can see the possible drawbacks.

I agree that the per-cgroup knob is better than the global one. We
should also find consensus whether the legacy semantic of k < u limit
should be preserved. It made sense to me at the time it was introduced
but I recall that Vladimir found it not really helpful when we discussed
that at LSF. I found it interesting e.g. for the rough task count
limiting use case which people were asking for.
-- 
Michal Hocko
SUSE Labs

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