On Wed, Nov 18, 2015 at 07:02:54PM +0300, Vladimir Davydov wrote: > On Tue, Nov 17, 2015 at 05:22:17PM -0500, Johannes Weiner wrote: > > On Tue, Nov 17, 2015 at 11:18:50PM +0300, Vladimir Davydov wrote: > > > And with this patch it will work this way, but only if sum limits < > > > total ram, which is rather rare in practice. On tightly packed > > > systems it does nothing. > > > > That's not true, it's still useful when things go south inside a > > cgroup, even with overcommitted limits. See above. > > I meant solely this patch here, not the rest of the patch set. In the > overcommitted case there is no difference if we have the last patch or > not AFAIU. Even this patch, and even in the overcommitted case. When things go bad inside a cgroup it can steal free memory (it's rare that machines are at 100% utilization in practice) or memory from other groups until it hits its own limit. I expect most users except, for some largescale deployments, to frequently hit memory.high (or max) in practice. Obviously the utopian case of full utilization will be even smoother when we make vmpressure more finegrained, but why would that be an argument *against* this patch here, which is useful everywhere else? > Why can't we apply all patches but the last one (they look OK at first > glance, but I need more time to review them carefully) and disable > socket accounting by default for now? Then you or someone else would > prepare a separate patch set introducing vmpressure propagation to > socket code, so that socket accounting could be enabled by default. This is not going to happen, and we discussed this several times before. I really wish Michal and you would put more thought into interface implications. It's trivial to fix up implementation if actual shortcomings are observed, but it's nigh impossible to fix interfaces and user-visible behavior once published. It requires enormous undertakings such as unified hierarchy to rectify things. Please take your time to review this series, no problem. But I'm no longer reacting to suggestions to make interface tradeoffs because new code is not proven to work 99% of the time. That's simply ridiculous. Any problems will have to be fixed either way, and we're giving users the cmdline options to work around them in the meantime. -- 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>