Messages in this thread | | | Date | Thu, 8 May 1997 21:06:13 +0000 (GMT) | From | Gerard Roudier <> | Subject | Re: Memory problems in pre-2.0.31 still present |
| |
On Thu, 8 May 1997, David S. Miller wrote:
> Date: Thu, 8 May 1997 16:06:02 +0200 (MEST) > From: Hubert Mantel <mantel@suse.de> > > The memory problems still exist in pre-2.0.31. > > I found a good way to reproduce it reliably: > > This means most likely that GFP_ATOMIC or GFP_BUFFER pages are being > requested when memory is very low, this will fail is not enough free > pages are available because try_to_free_page() cannot be called in > these two cases. The system would risk depleting the free page pool > entirely and deadlock if it did not do this.
I donnot think exactly so, at least about priorities usable by the buffer cache. GFP_ATOMIC is to be used under interrupt and obviously may often fail. However, there is no reason in theory this priority shall be used for buffer header allocations. I remember I've suggested to add some new priority that can allow to ask a page with the restriction this allocation will not attempt to do IO. I'm sure that works, because I've tried.
When priority is GFP_BUFFER, try_to_free_page is not called. If we try to call it, with some care, we just observe that shrink_mmap() frees page from the buffer cache in order to do its work. That eats CPU a lot. I've tried some change in order to avoid this weirdness, and it seemed to work.
I gave up from this changes because of the difficulty to anticipate effects of them. That takes lots of time for testing and seems to not improve things a lot.
In my opinion, the decision to change the buffer cache code in linux-2.0.30 has been a *bad* decision. Interactions between the buffer cache and other ones are very complex and my guess is that even authors have problems to understand what may happen in extreme situations.
On a system that does almost exclusively file reading, the number of free pages becomes very low. Since the buffer cache is unable to get pages from other one, if we try at this time some operations that involve heavily the buffer cache, Linux has gross problems ... Under 2.0.29, it eats CPU. Under 2.0.30 and 2.1.X I have experienced lock-up.
Regards, Gerard.
PS: The intended change of vmscan.c/try_to_free_page() in 2.0.31 has no effect on the buffer cache in my opinion.
| |