On Mon 07-09-15 13:01:10, Vladimir Davydov wrote: > On Mon, Sep 07, 2015 at 11:39:06AM +0200, Michal Hocko wrote: > ... > > > > 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. > > > > > > Personally, I'd prefer to have it switched on by default, because it > > > would force people test it and report bugs and performance degradation. > > > If one finds it really crappy, he/she should be able to disable it. > > > > I do not think this is the way of introducing new functionality. You do > > not want to force users to debug your code and go let it disable if it > > is too crappy. > > One must first enable CONFIG_KMEM, which is off by default. Yes, but let's be realistic here. People tend to use distribution kernels and so the config option will have to be enabled. > Anyway, we aren't talking about enabling it by default in the legacy > hierarchy, only in the unified hierarchy, which must be explicitly > enabled by passing __DEVEL__save_behavior. I think that's enough. But once it is set like that in default then it will stay even when the __DEVEL__ part is dropped. > > > > I agree that the per-cgroup knob is better than the global one. We > > > > > > Not that sure :-/ > > > > Why? > > I'm not sure there is use cases which need having kmem acct enabled in > one cgroup and disabled in another. What would be the downside though? It is true that all the static keys will be enabled in these configurations so even the non-enabled path would pay some overhead but that should be still close to unmeasurable (I haven't measured that so I might be wrong here). -- 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
