Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752705AbbDAPT1 (ORCPT ); Wed, 1 Apr 2015 11:19:27 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60974 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752400AbbDAPTX (ORCPT ); Wed, 1 Apr 2015 11:19:23 -0400 Date: Wed, 1 Apr 2015 17:19:20 +0200 From: Michal Hocko To: Dave Chinner Cc: Johannes Weiner , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds , Andrew Morton , Tetsuo Handa , Huang Ying , Andrea Arcangeli , "Theodore Ts'o" Subject: Re: [patch 00/12] mm: page_alloc: improve OOM mechanism and policy Message-ID: <20150401151920.GB23824@dhcp22.suse.cz> References: <1427264236-17249-1-git-send-email-hannes@cmpxchg.org> <20150326195822.GB28129@dastard> <20150327150509.GA21119@cmpxchg.org> <20150330003240.GB28621@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150330003240.GB28621@dastard> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1373 Lines: 29 On Mon 30-03-15 11:32:40, Dave Chinner wrote: > On Fri, Mar 27, 2015 at 11:05:09AM -0400, Johannes Weiner wrote: [...] > > GFP_NOFS sites are currently one of the sites that can deadlock inside > > the allocator, even though many of them seem to have fallback code. > > My reasoning here is that if you *have* an exit strategy for failing > > allocations that is smarter than hanging, we should probably use that. > > We already do that for allocations where we can handle failure in > GFP_NOFS conditions. It is, however, somewhat useless if we can't > tell the allocator to try really hard if we've already had a failure > and we are already in memory reclaim conditions (e.g. a shrinker > trying to clean dirty objects so they can be reclaimed). > > From that perspective, I think that this patch set aims force us > away from handling fallbacks ourselves because a) it makes GFP_NOFS > more likely to fail, and b) provides no mechanism to "try harder" > when we really need the allocation to succeed. You can ask for this "try harder" by __GFP_HIGH flag. Would that help in your fallback case? -- Michal Hocko SUSE Labs -- 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/