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

[Michal Hocko <mhocko@kernel.org>]

On Fri 04-09-15 12:18:45, Tejun Heo wrote:
> Hello, Michal.
> 
> On Fri, Sep 04, 2015 at 03:30:38PM +0200, Michal Hocko wrote:
> > 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.
> 
> So, I just ran small scale tests and I don't see any meaningful
> difference between kmemcg disabled and enabled for kbuild workload
> (limit is never reached in both cases, memory is reclaimed from global
> pressure).  The difference in kernel time usage.  I'm sure there's
> *some* overhead buried in the noise but given the current
> implementation, I can't see how enabling kmem would lead to 4%
> overhead in kbuild tests.  It isn't that kernel intensive to begin
> with.

OK, I've quickly rerun my test on 32CPU machine with 64G of RAM
Elapsed
logs.kmem: min: 68.10 max: 69.27 avg: 68.53 std: 0.53 runs: 3
logs.no.kmem: min: 64.08 [94.1%] max: 68.42 [98.8%] avg: 66.22 [96.6%] std: 1.77 runs: 3
User
logs.kmem: min: 867.68 max: 872.88 avg: 869.49 std: 2.40 runs: 3
logs.no.kmem: min: 865.99 [99.8%] max: 884.94 [101.4%] avg: 874.08 [100.5%] std: 7.98 runs: 3
System
logs.kmem: min: 78.50 max: 78.85 avg: 78.63 std: 0.16 runs: 3
logs.no.kmem: min: 75.36 [96.0%] max: 80.50 [102.1%] avg: 77.91 [99.1%] std: 2.10 runs: 3

The elapsed time is still ~3% worse in average while user and system are
in noise. I haven't checked where he overhead is coming from.
 
> > 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 don't think that's the right way to approach the problem.  Given
> that the cost isn't prohibitive, no user only care about a certain
> level of isolation willingly.

I haven't said it is prohibitive. It is simply non-zero and there is
always cost/benefit that should be considered.

> Distributing memory is what it's all about after all and memory is
> memory, user or kernel.

True except that kmem accounting doesn't cover the whole kernel memory
usage. It is an opt-in mechanism for a _better_ isolation. And the
question really is whether that better isolation is needed/requested by
default.

> We have kmem
> on/off situation for historical reasons and because the early
> implementation wasn't good enough to be enabled by default.  I get
> that there can be special cases, temporary or otherwise, where
> disabling kmem is desirable but that gotta be the exception, not the
> norm.

The default should be the cheapest one IMHO. And our overhead is really
close to 0 if no memcg accounting is enabled thanks to Johannes'
page_counters. Then we have a lightweight form of accounting (only user
memory) which is nicely defined. And then we have an additional opt-in
for a better isolation which involves some kernel memory as well. Why
should we conflate the last two? I mean, if somebody wants an additional
protection then sure, enable kmem and pay an additional overhead but why
to force this on everybody who wants to use memcg?
-- 
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>