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 from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
