Do you know any newer kernel that solves problem about "OOM Killer" ??
Thank you !!!!
> Do you know any newer kernel that solves problem about "OOM Killer" ??
> Thank you !!!!
I've had no problem with bogus out of memory cases in either 2.4.18-rc, or
the 2.4.18-ac tree (which adds the rmap vm improvements). I'm also working
at the moment on adding support for strict memory overcommit handling so
that you can opt to be sure OOM will not happen, and that a program will
always get out of memory returns from a syscall (or if you are really
really unlucky a kill from a stackfault on an app that doesnt take the
right care)
On 19 February 2002 08:02, Paco Martinez wrote:
> Do you know any newer kernel that solves problem about "OOM Killer" ??
>
> Thank you !!!!
Dont know whether it is in 2.4 mainline, but I use this small patch
--
vda
Author: M.H.VanLeeuwen <[email protected]>
--- linux.virgin/mm/vmscan.c Mon Dec 31 12:46:25 2001
+++ linux/mm/vmscan.c Fri Jan 11 18:03:05 2002
@@ -394,9 +394,9 @@
if (PageDirty(page) && is_page_cache_freeable(page) && page->mapping) {
/*
* It is not critical here to write it only if
- * the page is unmapped beause any direct writer
+ * the page is unmapped because any direct writer
* like O_DIRECT would set the PG_dirty bitflag
- * on the phisical page after having successfully
+ * on the physical page after having successfully
* pinned it and after the I/O to the page is finished,
* so the direct writes to the page cannot get lost.
*/
@@ -480,11 +480,14 @@
/*
* Alert! We've found too many mapped pages on the
- * inactive list, so we start swapping out now!
+ * inactive list.
+ * Move referenced pages to the active list.
*/
- spin_unlock(&pagemap_lru_lock);
- swap_out(priority, gfp_mask, classzone);
- return nr_pages;
+ if (PageReferenced(page) && !PageLocked(page)) {
+ del_page_from_inactive_list(page);
+ add_page_to_active_list(page);
+ }
+ continue;
}
/*
@@ -521,6 +524,9 @@
}
spin_unlock(&pagemap_lru_lock);
+ if (max_mapped <= 0 && (nr_pages > 0 || priority < DEF_PRIORITY))
+ swap_out(priority, gfp_mask, classzone);
+
return nr_pages;
}
I have seen some wierdness in this area. I think I might see how it comes
about.
The machine and configuration:
IBM x330 SMP 1.266 GHz Pentium III
2GB RAM
Rawhide 2.4.17-0.16 kernel
**NO SWAP**
Anyway, it appears that at some point the system is running low on
absolutely free RAM and the vmscan kicks in to try to free some pages. At
this point my top output says I have around 200MB of free memory and about
1.5GB of file cache so one could say this counts as shouldn't OOM anything.
If, at this point, I try to build both the i386 and i686 kernels from a
single rpm command (not sure if just running two sequential rpm -ba's does
it or not) I will start losing kdeinit's with the following showing up in
/var/log/messages:
kernel: Out of memory: Killed process 1630 (kdeinit)
(many more follow as the rpm processes continue valiantly trying to compile
kernels).
Somewhere along the lines here, try_to_free_pages in mm/vmscan.c is called
(not sure why, but doesn't matter, it just does). In do_try_to_free_pages
it calls page_launder, shrink_dcache_memory, shrink_icache_memory and
shirnk_dqcache_memory in succession and (eventually) if none of them frees
any pages and free_low(ANY_ZONE) > 0 then out of memory is declared.
Now here's the kick, if the gfp_mask indicates that this is a file system
(!(gfp_mask & __GFP_FS)) request then in shrink_dcache_memory there is a
blurb about a deadlock and the dcache refuses to release anything (no matter
how much it has: see shrink_dcache_memory in fs/dcache.c).
So it would appear to me that if the system is feeling some memory pressure
and the only thing that might be freeable is dcache and the file system asks
for some memory causing try_to_free_pages to be called, that you are just
SOL. dcache isn't giving you anything and there's nothing can be done about
it (well except implement the micro-suggestion in the DEADLOCK blurb in
dcache.c).
Anyway, I don't know if this helps or is even relevent, but I thought I'd
give it a whirl.
Jeff---
----- Original Message -----
From: "Alan Cox" <[email protected]>
To: "Paco Martinez" <[email protected]>
Cc: "kernel list" <[email protected]>
Sent: Tuesday, February 19, 2002 4:34 AM
Subject: Re: OOM killer
> > Do you know any newer kernel that solves problem about "OOM Killer" ??
> > Thank you !!!!
>
> I've had no problem with bogus out of memory cases in either 2.4.18-rc, or
> the 2.4.18-ac tree (which adds the rmap vm improvements). I'm also working
> at the moment on adding support for strict memory overcommit handling so
> that you can opt to be sure OOM will not happen, and that a program will
> always get out of memory returns from a syscall (or if you are really
> really unlucky a kill from a stackfault on an app that doesnt take the
> right care)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>