Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752641AbbKYUI2 (ORCPT ); Wed, 25 Nov 2015 15:08:28 -0500 Received: from gum.cmpxchg.org ([85.214.110.215]:46234 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752086AbbKYUI0 (ORCPT ); Wed, 25 Nov 2015 15:08:26 -0500 Date: Wed, 25 Nov 2015 15:08:06 -0500 From: Johannes Weiner To: Michal Hocko Cc: linux-mm@kvack.org, Andrew Morton , Linus Torvalds , Mel Gorman , David Rientjes , Tetsuo Handa , Rik van Riel , Hugh Dickins , Oleg Nesterov , Andrea Argangeli , LKML , Michal Hocko Subject: Re: [RFC PATCH] mm, oom: introduce oom reaper Message-ID: <20151125200806.GA13388@cmpxchg.org> References: <1448467018-20603-1-git-send-email-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1448467018-20603-1-git-send-email-mhocko@kernel.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1605 Lines: 38 Hi Michal, I think whatever we end up doing to smoothen things for the "common case" (as much as OOM kills can be considered common), we need a plan to resolve the memory deadlock situations in a finite amount of time. Eventually we have to attempt killing another task. Or kill all of them to save the kernel. It just strikes me as odd to start with smoothening the common case, rather than making it functionally correct first. On Wed, Nov 25, 2015 at 04:56:58PM +0100, Michal Hocko wrote: > A kernel thread has been chosen because we need a reliable way of > invocation so workqueue context is not appropriate because all the > workers might be busy (e.g. allocating memory). Kswapd which sounds > like another good fit is not appropriate as well because it might get > blocked on locks during reclaim as well. Why not do it directly from the allocating context? I.e. when entering the OOM killer and finding a lingering TIF_MEMDIE from a previous kill just reap its memory directly then and there. It's not like the allocating task has anything else to do in the meantime... > @@ -1123,7 +1126,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb, > continue; > } > /* If details->check_mapping, we leave swap entries. */ > - if (unlikely(details)) > + if (unlikely(details || !details->check_swap_entries)) > continue; && -- 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/