> 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.