> A few hour ago I've wrote:
>
> > 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.
>
> ... maybe true maybe wrong ... with the activation of try_to_free_page as
> Hubert wrote, it IS possible to run mke2fs on a mem=4MB system :-)))
>
> Sorry for the inconvenience
This patch allows the GFP_BUFFER priority allocations to be successfull
against all other caches. Indeed it should fix memory lack in some
situations, however the new balancing sheme may have very weird effect in
some quite normal situations.
For example, if you run concurrently reading and writing you probably
would get the following effects:
- CPU wasting.
- Swapping.
- Break read-ahead.
In my opinion, if a so simple solution would fix *really* the problem, it
would have been discovered and applied since months.
Just try to untar some large files from disk to disk and let us know what
happens (Or try some benchmarks like Bonnie ) ...
Regards, Gerard.