From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751915AbcGRPPL (ORCPT ); Mon, 18 Jul 2016 11:15:11 -0400 Received: from gum.cmpxchg.org ([85.214.110.215]:53212 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751320AbcGRPPH (ORCPT ); Mon, 18 Jul 2016 11:15:07 -0400 Date: Mon, 18 Jul 2016 11:14:45 -0400 From: Johannes Weiner To: Mikulas Patocka Cc: David Rientjes , Michal Hocko , Tetsuo Handa , Ondrej Kozina , Jerome Marchand , Stanislav Kozina , linux-mm@kvack.org, linux-kernel@vger.kernel.org, dm-devel@redhat.com, Dave Chinner Subject: Re: System freezes after OOM Message-ID: <20160718151445.GB14604@cmpxchg.org> References: <2d5e1f84-e886-7b98-cb11-170d7104fd13@I-love.SAKURA.ne.jp> <20160713133955.GK28723@dhcp22.suse.cz> <20160713145638.GM28723@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org CC Dave Chinner, who I recall had strong opinions on the mempool model The context is commit f9054c7 ("mm, mempool: only set __GFP_NOMEMALLOC if there are free elements"), which gives MEMALLOC/TIF_MEMDIE mempool allocations access to the system emergency reserves when there is no reserved object currently residing in the mempool. On Fri, Jul 15, 2016 at 07:21:59AM -0400, Mikulas Patocka wrote: > On Thu, 14 Jul 2016, David Rientjes wrote: > > > There is no guarantee that _anything_ can return memory to the mempool, > > You misunderstand mempools if you make such claims. Uhm, fully agreed. The point of mempools is that they have their own reserves, separate from the system reserves, to make forward progress in OOM situations. All mempool object holders promise to make forward progress, and when memory is depleted, the mempool allocations serialize against each other. In this case, every allocation has to wait for in-flight IO to finish to pass the reserved object on to the next IO. That's how the mempool model is designed. The commit in question breaks this by not waiting for outstanding object holders and instead quickly depletes the system reserves. That's a mempool causing a memory deadlock... David observed systems hanging 2+h inside mempool allocations. But where would an object holders get stuck? It can't be taking a lock that the waiting mempool_alloc() is holding, obviously. It also can't be waiting for another allocation, it makes no sense to use mempools to guarantee forward progress, but then have the whole sequence rely on an unguaranteed allocation to succeed after the mempool ones. So how could a system-wide OOM situation cause a mempool holder to hang? These hangs are fishy, but it seems reasonable to assume that somebody is breaking the mempool contract somewhere. The solution can not to be to abandon the mempool model. f9054c7 should be reverted.