From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751345AbdLIMob (ORCPT ); Sat, 9 Dec 2017 07:44:31 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:54089 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751195AbdLIMo2 (ORCPT ); Sat, 9 Dec 2017 07:44:28 -0500 Subject: Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending To: David Rientjes , Suren Baghdasaryan Cc: akpm@linux-foundation.org, mhocko@suse.com, hannes@cmpxchg.org, hillf.zj@alibaba-inc.com, minchan@kernel.org, mgorman@techsingularity.net, ying.huang@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, timmurray@google.com, tkjos@google.com References: <20171208012305.83134-1-surenb@google.com> From: Tetsuo Handa Message-ID: Date: Sat, 9 Dec 2017 21:44:20 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017/12/09 6:02, David Rientjes wrote: > On Thu, 7 Dec 2017, Suren Baghdasaryan wrote: > >> Slab shrinkers can be quite time consuming and when signal >> is pending they can delay handling of the signal. If fatal >> signal is pending there is no point in shrinking that process >> since it will be killed anyway. This change checks for pending >> fatal signals inside shrink_slab loop and if one is detected >> terminates this loop early. >> > > I've proposed a similar patch in the past, but for a check on TIF_MEMDIE, > which would today be a tsk_is_oom_victim(current), since we had observed > lengthy stalls in reclaim that would have been prevented if the oom victim > had exited out, returned back to the page allocator, allocated with > ALLOC_NO_WATERMARKS, and proceeded to quickly exit. > > I'm not sure that all fatal_signal_pending() tasks should get the same > treatment, but I understand the point that the task is killed and should > free memory when it fully exits. How much memory is unknown. > We can use __GFP_KILLABLE. Unless there is performance impact for checking fatal_siganl_pending(), allowing only fatal_signal_pending() threads with __GFP_KILLABLE to bail out (without using memory reserves) should be safe.