Messages in this thread | | | Date | Thu, 12 Jun 1997 14:56:12 +0200 | From | "Dr. Werner Fink" <> | Subject | Re: buffers vs. pages vs. kernel speed |
| |
> > 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
| |