[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20100602220429.F51E.A69D9226@jp.fujitsu.com>
Date: Wed, 2 Jun 2010 22:54:01 +0900 (JST)
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: David Rientjes <rientjes@...gle.com>
Cc: kosaki.motohiro@...fujitsu.com,
"Luis Claudio R. Goncalves" <lclaudio@...g.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Minchan Kim <minchan.kim@...il.com>, balbir@...ux.vnet.ibm.com,
Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Mel Gorman <mel@....ul.ie>, williams@...hat.com
Subject: Re: [RFC] oom-kill: give the dying task a higher priority
> > @@ -291,9 +309,10 @@ static struct task_struct *select_bad_process(unsigned long *ppoints,
> > * Otherwise we could get an easy OOM deadlock.
> > */
> > if (p->flags & PF_EXITING) {
> > - if (p != current)
> > + if (p != current) {
> > + boost_dying_task_prio(p, mem);
> > return ERR_PTR(-1UL);
> > -
> > + }
> > chosen = p;
> > *ppoints = ULONG_MAX;
> > }
>
> This has the potential to actually make it harder to free memory if p is
> waiting to acquire a writelock on mm->mmap_sem in the exit path while the
> thread holding mm->mmap_sem is trying to run.
if p is waiting, changing prio have no effect. It continue tol wait to release mmap_sem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists