Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752113AbbFHIVw (ORCPT ); Mon, 8 Jun 2015 04:21:52 -0400 Received: from cantor2.suse.de ([195.135.220.15]:38884 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbbFHIVk (ORCPT ); Mon, 8 Jun 2015 04:21:40 -0400 Date: Mon, 8 Jun 2015 10:21:37 +0200 From: Michal Hocko To: Tetsuo Handa Cc: rientjes@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] oom: always panic on OOM when panic_on_oom is configured Message-ID: <20150608082137.GD1380@dhcp22.suse.cz> References: <1433159948-9912-1-git-send-email-mhocko@suse.cz> <20150605111302.GB26113@dhcp22.suse.cz> <201506061551.BHH48489.QHFOMtFLSOFOJV@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201506061551.BHH48489.QHFOMtFLSOFOJV@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2130 Lines: 45 On Sat 06-06-15 15:51:35, Tetsuo Handa wrote: > Michal Hocko wrote: > > > > Let's move check_panic_on_oom up before the current task is > > > > checked so that the knob value is . Do the same for the memcg in > > > > mem_cgroup_out_of_memory. > > > > > > > > Reported-by: Tetsuo Handa > > > > Signed-off-by: Michal Hocko > > > > > > Nack, this is not the appropriate response to exit path livelocks. By > > > doing this, you are going to start unnecessarily panicking machines that > > > have panic_on_oom set when it would not have triggered before. If there > > > is no reclaimable memory and a process that has already been signaled to > > > die to is in the process of exiting has to allocate memory, it is > > > perfectly acceptable to give them access to memory reserves so they can > > > allocate and exit. Under normal circumstances, that allows the process to > > > naturally exit. With your patch, it will cause the machine to panic. > > > > Isn't that what the administrator of the system wants? The system > > is _clearly_ out of memory at this point. A coincidental exiting task > > doesn't change a lot in that regard. Moreover it increases a risk of > > unnecessarily unresponsive system which is what panic_on_oom tries to > > prevent from. So from my POV this is a clear violation of the user > > policy. > > For me, !__GFP_FS allocations not calling out_of_memory() _forever_ is a > violation of the user policy. Yes, the current behavior of GFP_NOFS is highly suboptimal, but this has _nothing_ what so ever to do with this patch and panic_on_oom handling. The former one is the page allocator proper while we are in the OOM killer layer here. This is not the first time you have done that. Please stop it. It makes a complete mess of the original discussions. [...] -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/