linux-kernel - Re: Improving OOM killer

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.1002031600490.27918@chino.kir.corp.google.com>
Date:	Wed, 3 Feb 2010 16:05:06 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Lubos Lunak <l.lunak@...e.cz>
cc:	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Rik van Riel <riel@...hat.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Nick Piggin <npiggin@...e.de>, Jiri Kosina <jkosina@...e.cz>
Subject: Re: Improving OOM killer

On Wed, 3 Feb 2010, Lubos Lunak wrote:

> > 	unsigned int badness(struct task_struct *p,
> > 					unsigned long totalram)
> > 	{
> > 		struct task_struct *child;
> > 		struct mm_struct *mm;
> > 		int forkcount = 0;
> > 		long points;
> >
> > 		task_lock(p);
> > 		mm = p->mm;
> > 		if (!mm) {
> > 			task_unlock(p);
> > 			return 0;
> > 		}
> > 		points = (get_mm_rss(mm) +
> > 				get_mm_counter(mm, MM_SWAPENTS)) * 1000 /
> > 				totalram;
> > 		task_unlock(p);
> >
> > 		list_for_each_entry(child, &p->children, sibling)
> > 			/* No lock, child->mm won't be dereferenced */
> > 			if (child->mm && child->mm != mm)
> > 				forkcount++;
> >
> > 		/* Forkbombs get penalized 10% of available RAM */
> > 		if (forkcount > 500)
> > 			points += 100;
> 
>  As far as I'm concerned, this is a huge improvement over the current code 
> (and, incidentally :), quite close to what I originally wanted). I'd be 
> willing to test it in few real-world desktop cases if you provide a patch.
> 

There're some things that still need to be worked out, like discounting 
hugetlb pages on each allowed node, respecting current's cpuset mems, 
etc., but I think it gives us a good rough draft of where we might end up.  
I did use the get_mm_rss() that you suggested, but I think it's more 
helpful in the context of a fraction of total memory allowed so the other 
heursitics (forkbomb, root tasks, nice'd tasks, etc) are penalizing the 
points in a known quantity rather than a manipulation of that baseline.

Do you have any comments about the forkbomb detector or its threshold that 
I've put in my heuristic?  I think detecting these scenarios is still an 
important issue that we need to address instead of simply removing it from 
consideration entirely.
--
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/