From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 13 Sep 2007 11:46:52 -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: pj@sgi.com, Andrea Arcangeli , linux-mm@kvack.org List-ID: On Thu, 13 Sep 2007, Christoph Lameter wrote: > > The problem is that cpuset_lock() is a mutex and doesn't exit the OOM > > killer immediately if it can't be locked. This is a problem that we've > > encountered before where multiple tasks enter the OOM killer and sleep > > waiting for the lock. Then one instance of the OOM killer kills current > > and the cpuset is no longer OOM, but the other threads waiting on the > > mutex will still kill tasks unnecessarily after taking cpuset_lock(). > > Ok then that needs to be changed. We need to do a cpuset_try_lock there? > It's easier to serialize it outside of out_of_memory() instead, since it only has a single caller and we don't need to serialize for sysrq. This seems like it would collapse down nicely to a global or per-cpuset serialization with an added helper function implemented partially in kernel/cpuset.c for the CONFIG_CPUSETS case. Then, in __alloc_pages(), we test for either a global or per-cpuset spin_trylock() and, if we acquire it, call out_of_memory() and goto restart as we currently do. If it's contended, we reschedule ourself and goto restart when we awaken. 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