david-b@pacbell.net said:
> Nobody's done that yet, and it's been a couple years now since that
> point was made as a desirable evolution path for pci_pool. In fact
> the first (only!) step on that path was the dma_pool update I just
> posted.
> Modifying the slab allocator like that means passing extra parameters
> around (for dma_addr_t), causing extra register pressure even for
> non-dma allocations. I have a hard time seeing that not slow things
> down, even on x86 (etc) where we know we can already get all the
> benefits of the slab allocator without any changes to that critical
> code.
I think the attached should do the necessary with no slow down in the slab
allocator.
Now all that has to happen for use with the dma pools is to wrapper
dma_alloc/free_coherent().
Note that the semantics won't be quite the same as the pci_pool one since you
can't guarantee that allocations don't cross the particular boundary
parameter. There's also going to be a reliance on the concept that the dma
coherent allocators will return a page bounded chunk of memory. Most seem
already to be doing this because the page properties are only controllable at
that level, so it shouldn't be a problem.
James
-
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 : Tue Dec 31 2002 - 22:00:19 EST