LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: pre4 oom too soon
2001-10-05 19:26 pre4 oom too soon Hugh Dickins
@ 2001-10-05 18:27 ` Marcelo Tosatti
2001-10-05 20:02 ` Linus Torvalds
2001-10-05 20:12 ` Linus Torvalds
2001-10-05 19:59 ` Linus Torvalds
1 sibling, 2 replies; 5+ messages in thread
From: Marcelo Tosatti @ 2001-10-05 18:27 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Linus Torvalds, Andrea Arcangeli, linux-kernel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* pre4 oom too soon
@ 2001-10-05 19:26 Hugh Dickins
2001-10-05 18:27 ` Marcelo Tosatti
2001-10-05 19:59 ` Linus Torvalds
0 siblings, 2 replies; 5+ messages in thread
From: Hugh Dickins @ 2001-10-05 19:26 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Linus Torvalds, Andrea Arcangeli, linux-kernel
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?
(I wonder whether, before my 2.4.10 fix to lowest_bit and highest_bit
in scan_swap_map, it was rarer to find nr_swap_pages 0 - swap pages
could be free, but invisible to scan_swap_map.)
Hugh
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: pre4 oom too soon
2001-10-05 19:26 pre4 oom too soon Hugh Dickins
2001-10-05 18:27 ` Marcelo Tosatti
@ 2001-10-05 19:59 ` Linus Torvalds
1 sibling, 0 replies; 5+ messages in thread
From: Linus Torvalds @ 2001-10-05 19:59 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Marcelo Tosatti, Andrea Arcangeli, linux-kernel
On Fri, 5 Oct 2001, Hugh Dickins wrote:
>
> 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?
That sounds sane. If we have swap cache pages, we're not out of memory
yet.
Linus
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: pre4 oom too soon
2001-10-05 18:27 ` Marcelo Tosatti
@ 2001-10-05 20:02 ` Linus Torvalds
2001-10-05 20:12 ` Linus Torvalds
1 sibling, 0 replies; 5+ messages in thread
From: Linus Torvalds @ 2001-10-05 20:02 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Hugh Dickins, Andrea Arcangeli, linux-kernel
On Fri, 5 Oct 2001, Marcelo Tosatti wrote:
>
> 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.
Why not just say "if we have swap cache pages, we aren't oom".
If we've scanned all lists twice, we should have unmapped all users of
swap-cache pages, and we should have dropped them.
And make the test be not quite black-and-white: we're almost always going
to have a _few_ swap-cache pages around under heavy memory load, if only
because of read-ahead etc that pins the pages. But if the swap cache is a
noticeable fraction of memory, we're obviously not oom _regardless_ of
what the VM balancers say.
Linus
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: pre4 oom too soon
2001-10-05 18:27 ` Marcelo Tosatti
2001-10-05 20:02 ` Linus Torvalds
@ 2001-10-05 20:12 ` Linus Torvalds
1 sibling, 0 replies; 5+ messages in thread
From: Linus Torvalds @ 2001-10-05 20:12 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Hugh Dickins, Andrea Arcangeli, linux-kernel
Actually, it looks like the easiest solution is to just remove the
cache_mem -= swapper_space.nrpages;
which should just automatically do the right thing.
Linus
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-10-05 20:13 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-05 19:26 pre4 oom too soon Hugh Dickins
2001-10-05 18:27 ` Marcelo Tosatti
2001-10-05 20:02 ` Linus Torvalds
2001-10-05 20:12 ` Linus Torvalds
2001-10-05 19:59 ` Linus Torvalds
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).