Re: Memory Problem in 2.4.10-pre2 / __alloc_pages failed

[Daniel Phillips]

On September 2, 2001 09:32 pm, Alex Bligh - linux-kernel wrote:
> Daniel,
> 
> > What do you do when a new module gets inserted, increasing the high order
> > load and requiring that the slab be expanded? I.e, the need for
> > dependable  handling of high order physical allocations doesn't go away
> > entirely.  The slab would help even out the situation with atomic allocs
> > because it can be expanded to a target size by a normal task, which can
> > wait.
> 
> Yes, chew away to disk as this allocation is non atomic.

What I meant was, the new module implements a network driver which proceeds 
to do atomic allocs.

> But this probably still needs something which goes and identifies
> kernel allocated pages with buddies which can be relocated / pushed to
> disk / freed etc.;
> 
> Alternatively something to temporarilly hold onto 'nearly freed'
> high-order areas is probably useful. IE if there's an order=3
> allocation stuck waiting for a suitable hole, and there's
> a bit of bitmap that looks like '00010000' (i.e. order 1 hole,
> order 0 hole, order 0 used, order 2 hole), I wonder if we can't
> think of some hueristic to avoid allocating the next order 0
> page request (atomic or not) from the order 0 hole even if
> it's at the front of the order (0) free area list.

One thing I am hearing from some developers is that we don't need to solve 
the high-order allocation problems because they are really driver issues - 
all drivers should be changed to use scatter-gather or some such.  I don't 
know if that's correct, this would require knowledge of all driver types and 
archs which I can't begin to claim.

I'm quite sure we can fix this up though, not to the point of being able to 
guarantee all high order allocations, but to the point where we have a high 
probability of success under all loads, as opposed to what we have now which 
is very fragile, and not just in the Linus tree.

--
Daniel