Re: Could not get a free page...

Gerard Roudier (groudier@club-internet.fr)
Thu, 5 Jun 1997 00:06:20 +0000 (GMT)


This buffer cache is broken in my opinion.

The modified buffer cache plays freeing/reallocating buffer headers at
GFP_ATOMIC priority. In my opinion, that can only be bad.

In my opinion, a new priority with a semantic of "atomic io" that
precludes try_to_free_pages() and friends from doing IO should be added.
That's enough for buffer header allocation at least.

On the other hand, the cache try blindly to allocate buffer headers
without taking into account the memory allocated for buffers.
What happens if there is no memory available?
'kswapd' can help, but that's just luck.

Gerard.

On Wed, 4 Jun 1997, Jakub Jelinek wrote:

> Andrew E. Mileski wrote:
> >
> > > Is anyone going to look into this or should I have a look at it?
> >
> > Hmmm...just for the heck of it, try increasing NR_REQUEST to something
> > like 256 (default 64).
>
> With echo 900 900 900 > /proc/sys/vm/freepages I could make the filesystem.
> But the issue is that this shouldn't be happenning, no matter how are free
> pages set up, especially when I run the O_SYNC mke2fs. With that, when the
> system locks up, I have about 8 dirty buffers, but more than 30000 clean
> buffers. Like that, I think every memory allocation request should succeed.
> But that's not the case. I've put a debugging printk into try_to_free_page,
> which was called only three times before the machine locked up, and always
> succeeded.