Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755359AbZFYEO1 (ORCPT ); Thu, 25 Jun 2009 00:14:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750762AbZFYEOT (ORCPT ); Thu, 25 Jun 2009 00:14:19 -0400 Received: from cantor.suse.de ([195.135.220.2]:44209 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750724AbZFYEOT (ORCPT ); Thu, 25 Jun 2009 00:14:19 -0400 Date: Thu, 25 Jun 2009 06:14:21 +0200 From: Nick Piggin To: Andrew Morton Cc: Linus Torvalds , penberg@cs.helsinki.fi, arjan@infradead.org, linux-kernel@vger.kernel.org, cl@linux-foundation.org, David Rientjes , Mel Gorman Subject: Re: upcoming kerneloops.org item: get_page_from_freelist Message-ID: <20090625041421.GB15782@wotan.suse.de> References: <4A426825.80905@cs.helsinki.fi> <20090624113037.7d72ed59.akpm@linux-foundation.org> <20090624120617.1e6799b5.akpm@linux-foundation.org> <20090624123624.26c93459.akpm@linux-foundation.org> <20090624130121.99321cca.akpm@linux-foundation.org> <20090624145615.2ff9e56e.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090624145615.2ff9e56e.akpm@linux-foundation.org> User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3608 Lines: 88 On Wed, Jun 24, 2009 at 02:56:15PM -0700, Andrew Morton wrote: > On Wed, 24 Jun 2009 13:13:48 -0700 (PDT) > Linus Torvalds wrote: > > This is not a new concept. oom has never been "immediately kill". > > Well, it has been immediate for a long time. A couple of reasons which > I can recall: > > - A page-allocating process will oom-kill another process in the > expectation that the killing will free up some memory. If the > oom-killed process remains stuck in the page allocator, that doesn't > work. > > - The oom-killed process might be holding locks (typically fs locks). > This can cause an arbitrary number of other processes to be blocked. > So to get the system unstuck we need the oom-killed process to > immediately exit the page allocator, to handle the NULL return and to > drop those locks. > > There may be other reasons - it was all a long time ago, and I've never > personally hacked on the oom-killer much and I never get oom-killed. > But given the amount of development work which goes on in there, some > people must be getting massacred. I think you are right Andrew. Any caller can fail. I suspect it is *very* rare to ever actually see failures because of the size of the reserves we keep, but the theoretical possibility is there. It would become rather more common with order->0 allocations too. But seeing as those are fairly infrequent in the page reclaim path (sans SLUB), then they are probably uncommon too. But to be completely safe from oopses, we need to annotate with GFP_NOFAIL or handle failures in the caller. > A long time ago, the Suse kernel shipped with a largely (or > completely?) disabled oom-killer. It removed the > retry-small-allocations-for-ever logic and simply returned NULL to the > caller. I never really understood what problem/thinking led Andrea to > do that. I think all 2.6 based ones are pretty close to upstream logic, however we have run into customers reporting OOM deadlocks that the OOM killer cannot resolve. I forget the exact details but they involve memory reserves being exhausted and killed tasks trying to allocate memory holding locks etc. > But it's all a bit moot at present, as we seem to have removed the > return-NULL-if-TIF_MEMDIE logic in Mel's post-2.6.30 merges. I think > that was an accident: > > - /* This allocation should allow future memory freeing. */ > - > rebalance: > - if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE))) > - && !in_interrupt()) { > - if (!(gfp_mask & __GFP_NOMEMALLOC)) { > -nofail_alloc: > - /* go through the zonelist yet again, ignoring mins */ > - page = get_page_from_freelist(gfp_mask, nodemask, order, > - zonelist, high_zoneidx, ALLOC_NO_WATERMARKS); > - if (page) > - goto got_pg; > - if (gfp_mask & __GFP_NOFAIL) { > - congestion_wait(WRITE, HZ/50); > - goto nofail_alloc; > - } > - } > - goto nopage; > + /* Allocate without watermarks if the context allows */ > + if (alloc_flags & ALLOC_NO_WATERMARKS) { > + page = __alloc_pages_high_priority(gfp_mask, order, > + zonelist, high_zoneidx, nodemask, > + preferred_zone, migratetype); > + if (page) > + goto got_pg; > } > > Offending commit 341ce06 handled the PF_MEMALLOC case but forgot about > the TIF_MEMDIE case. > > Mel is having a bit of downtime at present. -- 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/