Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751428AbcCKJUD (ORCPT ); Fri, 11 Mar 2016 04:20:03 -0500 Received: from mx2.parallels.com ([199.115.105.18]:57938 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751215AbcCKJTo (ORCPT ); Fri, 11 Mar 2016 04:19:44 -0500 Date: Fri, 11 Mar 2016 12:19:31 +0300 From: Vladimir Davydov To: Michal Hocko , Johannes Weiner CC: Andrew Morton , , , , Subject: Re: [PATCH] mm: memcontrol: reclaim and OOM kill when shrinking memory.max below usage Message-ID: <20160311091931.GK1946@esperanza> References: <1457643015-8828-2-git-send-email-hannes@cmpxchg.org> <20160311081825.GC27701@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160311081825.GC27701@dhcp22.suse.cz> X-ClientProxiedBy: US-EXCH2.sw.swsoft.com (10.255.249.46) To US-EXCH2.sw.swsoft.com (10.255.249.46) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 874 Lines: 32 On Fri, Mar 11, 2016 at 09:18:25AM +0100, Michal Hocko wrote: > On Thu 10-03-16 15:50:14, Johannes Weiner wrote: ... > > @@ -5037,9 +5040,36 @@ static ssize_t memory_max_write(struct kernfs_open_file *of, > > if (err) > > return err; > > > > - err = mem_cgroup_resize_limit(memcg, max); > > - if (err) > > - return err; > > + xchg(&memcg->memory.limit, max); > > + > > + for (;;) { > > + unsigned long nr_pages = page_counter_read(&memcg->memory); > > + > > + if (nr_pages <= max) > > + break; > > + > > + if (signal_pending(current)) { > > Didn't you want fatal_signal_pending here? At least the changelog > suggests that. I suppose the user might want to interrupt the write by hitting CTRL-C. Come to think of it, shouldn't we restore the old limit and return EBUSY if we failed to reclaim enough memory? > > > + err = -EINTR; > > + break; > > + }