Hello, Vladimir. On Mon, Sep 15, 2014 at 11:42:57AM +0400, Vladimir Davydov wrote: > > So, I'd love to see this happen too but I don't think we can do this. > > People use published interface. The usages might be utterly one-off > > and mental but let's please not underestimate the sometimes senseless > > creativity found in the wild. We simply can't remove a bunch of > > control knobs like this. > > We definitely can't remove something properly operating and widely used, > but kmem limits are not working and never worked properly due to lack of > kmem shrinkers, and furthermore CONFIG_MEMCG_KMEM, which tcp accounting > is enabled by, is marked as UNDER DEVELOPMENT. I don't think marking config options as "UNDER DEVELOPMENT" in its help documentation means anything. It's a rather silly thing to do. Not many people pay much attention to the help texts and once somebody somewhere enabled the option for a distro, it's as free in the wild as any other kernel feature and CONFIG_MEMCG_KMEM is enabled by a lot of distros. The same goes with the "debug" controller. It doesn't mean much that it has "debug" in its name. Once it's out in the wild, there will be someone making use of it in some weird way. If a debug feature has to be in the mainline kernel, the fact that it's a debug feature must be explicitly chosen in each use. IOW, gate it by an unwieldy boot param which makes it painfully clear that it's enabling an unstable debug feature and print out a loud warning message about it. As it currently stands, CONFIG_MEMCG_KMEM is as good as any other enabled kernel option. The help text saying that it's experimental does not mean anything especially when it doesn't even depend on CONFIG_BROKEN. So, the argument "the option was explained as experimental in help text" doesn't fly at all. We can still try to deprecate it gradually if the cleanup seems worthwhile; however, with v2 interface pending, I'm not sure how meaningful that'd be. We'd have to carry quite a bit of v1 code around anyway and I'd like to keep v1 interface as static as possible. No reason to shake that at this point. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>