> This should apply to any recent 2.0.3X kernel, I believe it should
> help with the situations such as "my 4MB ram machine hangs when you
> try to make a 9gb ext2 partition with mke2fs" and this sort of thing.
>
> Warning, I ran it though my tests, but I need others to be brave
> enough to test it, I also want feedback from the people who can
> reproduce it easily with existing kernels. I'd like to know if this
> fixes it, or just makes it a little better, or makes it worse 8-)
I agree that this idea shall work, however we must be very carefull doing
that. This change may have some very bad effect too. I 've tried such
a change.
In my opinion, GFP_BUFFER should remain a low priority for allocations.
On the other hand, buffer headers shall be allocated with a high priority
and such allocations shall be able to victimize buffers if necessary.
So, we must add a special priority level for buffer headers allocations.
Remember that shrink_mmap() calls try_to_free_buffer(). If this function
is called for GFP_BUFFER without any other information, grow_buffers()
may just allocate memory that shrink_mmap() a freed from the cache.
This weird situation just eat CPU for nothing.
The same way we try to get memory from other caches when memory
becomes low, we must increase reusability of buffers in buffer.c.
This stuff is very hard to tune, at least by me.
If we call GFP_ATOMIC_IO the new priority that can be added for buffer
header allocations, shrink_mmap behaviour should be changed as follow:
- When priority is GFP_ATOMIC_IO, call try_to_free_buffers().
- When priority is GFP_BUFFER, donnot call try_to_free_buffer().
(We must add a flag in order to pass this info to shrink_mmap())
Very probably, some other improvements are necessary in order to make
working that stuff, especially if we donnot want to waste CPU due to
memory being heavily freed and allocated among caches.
So, in my opinion, we should also learn caches to reuse their memory in
some situations (but which situations ?)
Gerard.