Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 29 Jun 2018 09:21:32 +0200
From:   Michal Hocko <mhocko@kernel.org>
To:     Greg Thelen <gthelen@google.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Shakeel Butt <shakeelb@google.com>, linux-mm@kvack.org,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] memcg, oom: move out_of_memory back to the charge path
Message-ID: <20180629072132.GA13860@dhcp22.suse.cz>
References: <20180628151101.25307-1-mhocko@kernel.org>
 <xr93in62jy8k.fsf@gthelen.svl.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <xr93in62jy8k.fsf@gthelen.svl.corp.google.com>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu 28-06-18 16:19:07, Greg Thelen wrote:
> Michal Hocko <mhocko@kernel.org> wrote:
[...]
> > +	if (mem_cgroup_out_of_memory(memcg, mask, order))
> > +		return OOM_SUCCESS;
> > +
> > +	WARN(1,"Memory cgroup charge failed because of no reclaimable memory! "
> > +		"This looks like a misconfiguration or a kernel bug.");
> 
> I'm not sure here if the warning should here or so strongly worded.  It
> seems like the current task could be oom reaped with MMF_OOM_SKIP and
> thus mem_cgroup_out_of_memory() will return false.  So there's nothing
> alarming in that case.

If the task is reaped then its charges should be released as well and
that means that we should get below the limit. Sure there is some room
for races but this should be still unlikely. Maybe I am just
underestimating though.

What would you suggest instead?
-- 
Michal Hocko
SUSE Labs