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 - 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/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:15 EST