Messages in this thread | | | Date | Tue, 13 Oct 1998 20:54:58 +0200 (CEST) | From | Rik van Riel <> | Subject | Re: 2.1.125 Show stopper list: Draft |
| |
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/
| |