From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751821Ab3KSBTG (ORCPT ); Mon, 18 Nov 2013 20:19:06 -0500 Received: from mail-yh0-f42.google.com ([209.85.213.42]:62852 "EHLO mail-yh0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751503Ab3KSBTD (ORCPT ); Mon, 18 Nov 2013 20:19:03 -0500 Date: Mon, 18 Nov 2013 17:19:00 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Michal Hocko cc: Andrew Morton , Johannes Weiner , KAMEZAWA Hiroyuki , linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, "Eric W. Biederman" Subject: Re: [patch 1/2] mm, memcg: avoid oom notification when current needs access to memory reserves In-Reply-To: <20131118125507.GD32623@dhcp22.suse.cz> Message-ID: References: <20131031054942.GA26301@cmpxchg.org> <20131113233419.GJ707@cmpxchg.org> <20131114032508.GL707@cmpxchg.org> <20131118125240.GC32623@dhcp22.suse.cz> <20131118125507.GD32623@dhcp22.suse.cz> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 Nov 2013, Michal Hocko wrote: > > > When current has a pending SIGKILL or is already in the exit path, it > > > only needs access to memory reserves to fully exit. In that sense, the > > > memcg is not actually oom for current, it simply needs to bypass memory > > > charges to exit and free its memory, which is guarantee itself that > > > memory will be freed. > > > > > > We only want to notify userspace for actionable oom conditions where > > > something needs to be done (and all oom handling can already be deferred > > > to userspace through this method by disabling the memcg oom killer with > > > memory.oom_control), not simply when a memcg has reached its limit, which > > > would actually have to happen before memcg reclaim actually frees memory > > > for charges. > > > > I believe this also fixes the issue reported by Eric > > (https://lkml.org/lkml/2013/7/28/74). I had a patch for this > > https://lkml.org/lkml/2013/7/31/94 but the code changed since then and > > this should be equivalent. > > > > > Reported-by: Johannes Weiner > > > Signed-off-by: David Rientjes > > Anyway, the patch looks good to me but please mention the above bug in > the changelog. > The patch is in -mm, so perhaps we can change the changelog if/when Eric confirms it fixes his issue. > Acked-by: Michal Hocko > Thanks!