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