Messages in this thread |  | | Date | Fri, 5 Oct 2001 15:27:02 -0300 (BRT) | From | Marcelo Tosatti <> | Subject | Re: pre4 oom too soon |
| |
On Fri, 5 Oct 2001, Hugh Dickins wrote:
> 2.4.11-pre4 gives me oom_kill I never got before. > All numbers decimal in 4kB pages: > > num_physpages 65520 > free or freeable 56000 (from MemFree after swapoff afterwards) > total_swap_pages 132526 > prog tries to hog 153600 > > At oom_kill time: > > all_zones_low yes (DMA & Normal well above min, no Highmem) > nr_swap_pages 0 > page_cache_size 59013 > swapper_space.nrpages 58202 > > I'm not sure exactly what to blame in out_of_memory(), but it does > look wrong to depend so much on whether nr_swap_pages happens to be > 0 at that instant or not, and a lot of that full swap is duplicated > in the swap cache. Probably that should be taken into consideration?
The issue is that right now we're going to _check_ for OOM each time kswapd_balance_pgdat is not able to make all zones have enough free pages: That is way too fragile (I submitted the patch to Linus saying that it was just a previa, and he included it anyway.. :))
do { need_more_balance = 0; pgdat = pgdat_list; do need_more_balance |= kswapd_balance_pgdat(pgdat); while ((pgdat = pgdat->node_next)); if (need_more_balance && out_of_memory()) { oom_kill(); } } while (need_more_balance);
Note that a full kswapd_balance_pgdat() is going to scan only a small portion of the lists. I'm pretty sure we have to guarantee kswapd scanned at least all lists (maybe scanned all lists twice), before checking for OOM.
I guess I'll not be able to write a patch to give us that behaviour _today_, but I'll do so Monday if nobody else does.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |