From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 3 Jan 2008 01:56:41 +0100 From: Andrea Arcangeli Subject: Re: [PATCH 08 of 24] don't depend on PF_EXITING tasks to go away Message-ID: <20080103005641.GI30939@v2.random> References: <20070912052032.dfbba2e4.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070912052032.dfbba2e4.akpm@linux-foundation.org> Sender: owner-linux-mm@kvack.org Return-Path: To: Andrew Morton Cc: linux-mm@kvack.org, David Rientjes List-ID: On Wed, Sep 12, 2007 at 05:20:32AM -0700, Andrew Morton wrote: > 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? By memory yes. -- 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