From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 19 Sep 2007 11:21:58 -0700 (PDT) From: David Rientjes Subject: Re: [patch 6/4] oom: pass null to kfree if zonelist is not cleared In-Reply-To: <20070919100922.16be90c0.pj@sgi.com> Message-ID: References: <871b7a4fd566de081120.1187786931@v2.random> <20070919100922.16be90c0.pj@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Paul Jackson Cc: clameter@sgi.com, akpm@linux-foundation.org, andrea@suse.de, linux-mm@kvack.org List-ID: On Wed, 19 Sep 2007, Paul Jackson wrote: > David wrote: > > Why would it be constrained by the cpuset policy if there is no > > __GFP_HARDWALL? > > Er eh ... because it is ;) > > With or without GFP_HARDWALL, allocations are constrained by cpuset > policy. > > It's just a different policy (the nearest ancestor cpuset marked > mem_exclusive) without GFP_HARDWALL, rather than the current cpuset. > The question is: why do we care? I don't understand why it makes so much of a difference if the kzalloc fails and we fall back to non-serialized behavior, even though the updated patchset sets PF_MEMALLOC in current to avoid watermarks in its allocation. We could set TIF_MEMDIE in current momentarily only for the kzalloc, but I think it's unnecessary and possibly troublesome because that task can be detected in parallel OOM killings and it suddenly becomes a no-op. Even if we aren't serialized, the parallel OOM-killed task will be marked TIF_MEMDIE and we'll detect that and not kill anything because we've serialized on callback_mutex. David -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org