[lkml]   [2001]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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;
need_more_balance |= kswapd_balance_pgdat(pgdat);
while ((pgdat = pgdat->node_next));
if (need_more_balance && out_of_memory()) {
} 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

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:04    [W:0.032 / U:0.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site