From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 18 Sep 2007 09:44:34 -0700 (PDT) From: David Rientjes Subject: Re: [PATCH 04 of 24] serialize oom killer In-Reply-To: Message-ID: References: <871b7a4fd566de081120.1187786931@v2.random> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Andrea Arcangeli , linux-mm@kvack.org List-ID: On Thu, 13 Sep 2007, David Rientjes wrote: > We have no way of locking only the nodes in the MPOL_BIND memory policy > like we do on a cpuset granularity. That would require an spinlock in > each node which would work fine if we alter the CONSTRAINT_CPUSET case to > lock each node in current->cpuset->mems_allowed. We could do that if add > a task_lock(current) before trying oom_test_and_set_lock() in > __alloc_pages(). > > There's also no OOM locking at the zone level for GFP_DMA constrained > allocations, so perhaps locking should be on the zone level. > There's a way to get around adding a spinlock to struct zone by just saving the pointers of the zonelists passed to __alloc_pages() when the OOM killer is invoked. Then, on subsequent calls to out_of_memory(), it is possible to scan through the list of zones that already have a corresponding allocation attempt that has failed and is already in the OOM killer. Hopefully the OOM killer will kill a memory-hogging task, which the heuristics are pretty good for, and it will free up some space in those zones. Thus, we should indeed be serializing on the zone level instead of node or cpuset level. 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