On Wed, Mar 16, 2016 at 01:13:29PM -0700, Johannes Weiner wrote: > On Wed, Mar 16, 2016 at 06:15:09PM +0300, Vladimir Davydov wrote: > > On Tue, Mar 15, 2016 at 10:18:48PM -0700, Johannes Weiner wrote: > > > On Fri, Mar 11, 2016 at 12:19:31PM +0300, Vladimir Davydov wrote: > > ... > > > > Come to think of it, shouldn't we restore the old limit and return EBUSY > > > > if we failed to reclaim enough memory? > > > > > > I suspect it's very rare that it would fail. But even in that case > > > it's probably better to at least not allow new charges past what the > > > user requested, even if we can't push the level back far enough. > > > > It's of course good to set the limit before trying to reclaim memory, > > but isn't it strange that even if the cgroup's memory can't be reclaimed > > to meet the new limit (tmpfs files or tasks protected from oom), the > > write will still succeed? It's a rare use case, but still. > > It's not optimal, but there is nothing we can do about it, is there? I > don't want to go back to the racy semantics that allow the application > to balloon up again after the limit restriction fails. > > > I've one more concern regarding this patch. It's about calling OOM while > > reclaiming cgroup memory. AFAIU OOM killer can be quite disruptive for a > > workload, so is it really good to call it when normal reclaim fails? > > > > W/o OOM killer you can optimistically try to adjust memory.max and if it > > fails you can manually kill some processes in the container or restart > > it or cancel the limit update. With your patch adjusting memory.max > > never fails, but OOM might kill vital processes rendering the whole > > container useless. Wouldn't it be better to let the user decide if > > processes should be killed or not rather than calling OOM forcefully? > > Those are the memory.max semantics, though. Why should there be a > difference between the container growing beyond the limit and the > limit cutting into the container? > > If you don't want OOM kills, set memory.high instead. This way you get > the memory pressure *and* the chance to do your own killing. Fair enough. Thanks, Vladimir -- 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>