Re: Memory Problem in 2.4.10-pre2 / __alloc_pages failed

[Alex Bligh - linux-kernel]

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.

I think I was agreeing with you, but I think what you meant was
that when you load the module, it expands the slab, but with
a /non-atomic/ alloc. And what I meant was that as the
page reclaim stuff is dumb in terms of recovering buddies
of existing pages, it will chew away for a good while until
it happens to find a large enough hole. But this isn't really
a problem if it happens on module load only.

> 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.

We have lots of interesting current restrictions, like we assume
IP packets are contiguous in memory, and we assume we can allocate
their buffers atomically. I suspect there will not be many fans
of non-contiguous IP packet models. [Historics: the buddy system
was originally introduced to cope with fragments which reassembled
to >4k in length, though devices like HSSI with 4470 byte MTU's
are going to have the same problem without fragmentation]

No argument that scatter/gather is better if possible & practical
(SCSI comes to mind).

--
Alex Bligh