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:   Mon, 2 Jul 2018 12:03:01 +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: <20180702100301.GC19043@dhcp22.suse.cz>
References: <20180628151101.25307-1-mhocko@kernel.org>
 <xr93in62jy8k.fsf@gthelen.svl.corp.google.com>
 <20180629072132.GA13860@dhcp22.suse.cz>
 <xr93bmbtju6f.fsf@gthelen.svl.corp.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <xr93bmbtju6f.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 Fri 29-06-18 11:59:04, Greg Thelen wrote:
> Michal Hocko <mhocko@kernel.org> wrote:
> 
> > 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?
> 
> I suggest checking MMF_OOM_SKIP or deleting the warning.

So what do you do when you have MMF_OOM_SKIP task? Do not warn? Checking
for all the tasks would be quite expensive and remembering that from the
task selection not nice either. Why do you think it would help much?

I feel strongly that we have to warn when bypassing the charge limit
during the corner case because it can lead to unexpected behavior and
users should be aware of this fact. I am open to the wording or some
optimizations. I would prefer the latter on top with a clear description
how it helped in a particular case though. I would rather not over
optimize now without any story to back it.
-- 
Michal Hocko
SUSE Labs