From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 12 Sep 2007 05:20:32 -0700 From: Andrew Morton Subject: Re: [PATCH 08 of 24] don't depend on PF_EXITING tasks to go away Message-Id: <20070912052032.dfbba2e4.akpm@linux-foundation.org> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Andrea Arcangeli Cc: linux-mm@kvack.org, David Rientjes List-ID: On Wed, 22 Aug 2007 14:48:55 +0200 Andrea Arcangeli wrote: > # HG changeset patch > # User Andrea Arcangeli > # Date 1187778125 -7200 > # Node ID ffdc30241856d7155ceedd4132eef684f7cc7059 > # Parent b66d8470c04ed836787f69c7578d5fea4f18c322 > don't depend on PF_EXITING tasks to go away > > A PF_EXITING task don't have TIF_MEMDIE set so it might get stuck in > memory allocations without access to the PF_MEMALLOC pool (said that > ideally do_exit would better not require memory allocations, especially > not before calling exit_mm). The same way we raise its privilege to > TIF_MEMDIE if it's the current task, we should do it even if it's not > the current task to speedup oom killing. > > Signed-off-by: Andrea Arcangeli > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -234,27 +234,13 @@ static struct task_struct *select_bad_pr > * Note: this may have a chance of deadlock if it gets > * blocked waiting for another task which itself is waiting > * for memory. Is there a better alternative? > + * > + * Better not to skip PF_EXITING tasks, since they > + * don't have access to the PF_MEMALLOC pool until > + * we select them here first. > */ > if (test_tsk_thread_flag(p, TIF_MEMDIE)) > return ERR_PTR(-1UL); > - > - /* > - * This is in the process of releasing memory so wait for it > - * to finish before killing some other task by mistake. > - * > - * However, if p is the current task, we allow the 'kill' to > - * go ahead if it is exiting: this will simply set TIF_MEMDIE, > - * which will allow it to gain access to memory reserves in > - * the process of exiting and releasing its resources. > - * Otherwise we could get an easy OOM deadlock. > - */ > - if (p->flags & PF_EXITING) { > - if (p != current) > - return ERR_PTR(-1UL); > - > - chosen = p; > - *ppoints = ULONG_MAX; > - } > > if (p->oomkilladj == OOM_DISABLE) > continue; > hm, I'll believe you. Does this address any problem which was actually observed in real life? -- 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