From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f71.google.com (mail-pl0-f71.google.com [209.85.160.71]) by kanga.kvack.org (Postfix) with ESMTP id E128F6B000C for ; Tue, 24 Jul 2018 20:24:34 -0400 (EDT) Received: by mail-pl0-f71.google.com with SMTP id w1-v6so4014578ply.12 for ; Tue, 24 Jul 2018 17:24:34 -0700 (PDT) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id d13-v6sor3538602pgt.331.2018.07.24.17.24.33 for (Google Transport Security); Tue, 24 Jul 2018 17:24:33 -0700 (PDT) Date: Tue, 24 Jul 2018 17:24:31 -0700 (PDT) From: David Rientjes Subject: Re: [patch v4] mm, oom: fix unnecessary killing of additional processes In-Reply-To: Message-ID: References: <05dbc69a-1c26-adec-15c6-f7192f8d2ae0@i-love.sakura.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Tetsuo Handa Cc: Andrew Morton , Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org On Wed, 25 Jul 2018, Tetsuo Handa wrote: > > If exit_mmap() gets preempted indefinitely before it can free any memory, > > we are better off oom killing another process. The purpose of the timeout > > is to give an oom victim an amount of time to free its memory and exit > > before selecting another victim. > > > > There is no point with emitting the noise. > If you're concerned about too many printk's to the kernel log, oom_reap_task_mm() could store whether MMF_UNSTABLE was set or not before attempting to reap and then only printk if this was the first oom reaping. We lose the ability to determine if subsequent reaps freed additional memory, but I don't suppose that's too concerning.