Re: buffers vs. pages vs. kernel speed

Dr. Werner Fink (werner@suse.de)
Thu, 12 Jun 1997 14:56:12 +0200


> > Let's try this one... this has:
> >
> > 1) buffer cache clean buffer out of memory fixes
> > 2) handle multi-page allocations in low memory situations
> > (sans GFP_ATOMIC) more gracefully
> > 3) Matthias's state machine fix
> > 4) Debugging code added to try_to_free_page() for when it fails
> >
> > I ran a kernel compile in 3mb of ram on a Sparc (which makes the
> > machine useless, _very_ useless) and as far as it got (I let it run
> > for a day, I wasn't going to let it finish) it did not allow one
> > try_to_free_page() to fail, not once.
>
> With this patch on a pre-2.0.31-2 Kernel I tried to create the 1Gig
> filesystem on a 4MB machine. Until now I tried it three times and it
> failed twice ;-(

Hmmm ... in case of mem=4MB and a buffer request larger or equal than 4MB
Matthias's state machine fix runs into trouble. In such situations
the buffer of the requesting process must shrinked to get enough free mem
space for the new buffer ... try_to_free_page should not turn to shm_swap or
swap_out but have to shrink the buffer/shared pages. This costs cpu time
but it's really necessary to get the requesting programm (mke2fs) running.

On the other hand: If there is much more mem space as the requested mem
Matthias's state machine fix is the better choice to save cpu time and
to avoid the nasty sig7/Couldn't_get_free_page problem. That is also what
Gerard reports.

We need a switch for both situations. Also my previous hack in shrink_mmap
is a bad one for the first scenario.

>
> Hubert mantel@suse.de
>

Werner