linux-kernel - Re: [RFC] oom-kill: give the dying task a higher priority

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1006021410300.32666@chino.kir.corp.google.com>
Date:	Wed, 2 Jun 2010 14:11:47 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
cc:	"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

On Wed, 2 Jun 2010, KOSAKI Motohiro wrote:

> > > @@ -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.
> 

And that can reduce the runtime of the thread holding a writelock on 
mm->mmap_sem, making the exit actually take longer than without the patch 
if its priority is significantly higher, especially on smaller machines.
--
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/