Re: Memory Problem in 2.4.10-pre2 / __alloc_pages failed

Daniel Phillips (phillips@bonn-fries.net)
Sun, 2 Sep 2001 22:33:41 +0200


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/