Re: 2.1.125 Show stopper list: Draft

Rik van Riel (H.H.vanRiel@phys.uu.nl)
Tue, 13 Oct 1998 20:54:58 +0200 (CEST)


On Tue, 13 Oct 1998, Andrea Arcangeli wrote:
> On Tue, 13 Oct 1998, Rik van Riel wrote:
>
> >> If we are not OOM and __get_free_pages() return 0, it means that
> >> it's buggy (at least in _not_ GFP_ATOMIC context).
> >It can also mean something else, but I think I've explained
>
> If it' s something else (there is plenty of memory)

s/memory/swap/

> __get_free_pages() is buggy. We are failing a memory allocation
> while we should not fail because there are 500Mbyte of RAM/swap
> free.

Andrea, please consider the _theoretical_ possibility
that all pages we scan have been touched since we last
scanned them; that would mean we can't free any of them
on _this_ pass, but we can free them on the next pass.

A situation like this can also occur when we still have
loads of free swap left.

This possibility is very easy to see, and although it
should be very very very rare, you can bet on it that
someone will be bitten by this 'property' of the code.

That is why I want to implement a make_sure_we_are_OOM()
test, just to make sure that we don't kill something when
an extra try of try_to_free_page() could have found a
page to free.

> If __get_free_pages() would fail when not OOM you would noticed
> that, be quiet.

People have noticed that. I have personally seen it during
the 2.1.8x days, when kswapd was going through a transition.

Because kswapd will most likely face another transition when
we enter 2.3, me should make the code as failsafe as possible,
so things don't break down when we change something else.

> Please reproduce. Be sure that until somebody will tell me a way to
> reproduce on his machine the failed memory allocation I will not
> touch one bit in my code.

Damnit, Andrea! I have outlined the _theoretical_
possibility of it happening _and_ the easy yet
complete fix. The fix is readily available from my
home page and I am willing to do the integration
(next week, when my exam is past).

What is wrong with that approach?

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/