From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752142AbcGTG3S (ORCPT ); Wed, 20 Jul 2016 02:29:18 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:38109 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751230AbcGTG3Q (ORCPT ); Wed, 20 Jul 2016 02:29:16 -0400 Date: Wed, 20 Jul 2016 08:29:12 +0200 From: Michal Hocko To: Andrew Morton Cc: linux-mm@kvack.org, Tetsuo Handa , David Rientjes , Oleg Nesterov , Vladimir Davydov , LKML Subject: Re: [PATCH 10/10] mm, oom: hide mm which is shared with kthread or global init Message-ID: <20160720062912.GA11249@dhcp22.suse.cz> References: <1466426628-15074-1-git-send-email-mhocko@kernel.org> <1466426628-15074-11-git-send-email-mhocko@kernel.org> <20160719120538.GE9490@dhcp22.suse.cz> <20160719162759.e391c685db7a8de30b79320c@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160719162759.e391c685db7a8de30b79320c@linux-foundation.org> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 19-07-16 16:27:59, Andrew Morton wrote: > On Tue, 19 Jul 2016 14:05:39 +0200 Michal Hocko wrote: > > > > After this patch we should guarantee a forward progress for the OOM > > > killer even when the selected victim is sharing memory with a kernel > > > thread or global init. > > > > Could you replace the last two paragraphs with the following. Tetsuo > > didn't like the guarantee mentioned there because that is a too strong > > statement as find_lock_task_mm might not find any mm and so we still > > could end up looping on the oom victim if it gets stuck somewhere in > > __mmput. This particular patch didn't aim at closing that case. Plugging > > that hole is planned later after the next upcoming merge window closes. > > > > " > > In order to help a forward progress for the OOM killer, make sure > > that this really rare cases will not get into the way and hide > > the mm from the oom killer by setting MMF_OOM_REAPED flag for it. > > oom_scan_process_thread will ignore any TIF_MEMDIE task if it has > > MMF_OOM_REAPED flag set to catch these oom victims. > > > > After this patch we should guarantee a forward progress for the OOM > > killer even when the selected victim is sharing memory with a kernel > > thread or global init as long as the victims mm is still alive. > > " > > I tweaked it a bit: > > : In order to help forward progress for the OOM killer, make sure that > : this really rare case will not get in the way - we do this by hiding > : the mm from the oom killer by setting MMF_OOM_REAPED flag for it. > : oom_scan_process_thread will ignore any TIF_MEMDIE task if it has > : MMF_OOM_REAPED flag set to catch these oom victims. > : > : After this patch we should guarantee forward progress for the OOM > : killer even when the selected victim is sharing memory with a kernel > : thread or global init as long as the victims mm is still alive. Sounds good to me. Thanks! -- Michal Hocko SUSE Labs