[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] a simple OOM killer to save me from Netscape
On Thu, 12 Apr 2001 15:25:00 -0300 (BRST), you wrote:
>On Thu, 12 Apr 2001, Slats Grobnik wrote:
>
> [snip special-purpose part]
>
>> By running `free -s1' or `top' it's clear that once swap memory gets
>> maxed out, *cache* memory size decreases until, at about 4M, mouse &
>> keyboard response becomes noticeably sluggish. At cache=3M or less,
>> all hope is lost. But at this point, *free* RAM size may not be
>> affected much. And since CPU activity is down to a crawl, it may
>> take a while to reach minimum (or some small arbitrary figure.)
>> So I altered the `out_of_memory' function accordingly, and expect to
>> never reboot again. (Except for changing kernels, and power outage.
>
>*nod* We need to OOM-kill before we're dead in the water due to
>thrashing.
>
>> - /*
>> - * Niced processes are most likely less important, so double
>> - * their badness points.
>> - */
>> - if (p->nice > 0)
>> - points *= 2;
>> + /* Niced processes less important? Distributed.net would disagree! */
>
>Agreed. A while ago there was a discussion about this and we
>agreed that we should remove this test (only, we never got
>around to sending something to Linus ;)).
>
>
>> - /* Enough free memory? Not OOM. */
>> - if (nr_free_pages() > freepages.min)
>> - return 0;
>> + /* Even if free memory stays big enough... */
>> + /* ...a cramped cache means thrashing, then keyboard lockout. */
>>
>> - if (nr_free_pages() + nr_inactive_clean_pages() > freepages.low)
>> + if ((atomic_read(&page_cache_size) << PAGE_SHIFT) > (3 << 20)-1 )
>> return 0;
>
>1) you DO need to check to see if the system still has enough
> free pages
>2) the cache size may be better expressed as some percentage
> of system memory ... it's still not good, but the 3 MB you
> chose is probably completely wrong for 90% of the systems
> out there ;)
>
>I believe Andrew Morton was also looking at making changes to the
>out_of_memory() function, but only to make sure the OOM killer
>isn't started to SOON. I guess we can work something out that will
>both kill soon enough *and* not too soon ;)
A manual (SysRq?) way of triggering the killer would be nice too. A
couple of times now I've had a process (usually the Acrobat Reader)
chomp a few hundred Mb of swap, causing horrible swapping. Had the OOM
killer triggered, it would have blown the rogue process away straight
away - except I couldn't trigger it manually...
>Any suggestions for making Slats' ideas more generic so they work
>on every system ?
How about setting a "target" cache size - so if the cache drops below
X Mb, you consider the system OOM and call up the firing squad?
James.
--
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.eu.org/Linux-MM/