On Tue, 11 Jun 2002 14:04, Roland Dreier wrote:
> >>>>> "David" == David S Miller <davem@redhat.com> writes:
>
> David> Wait a second, forget all of this cache alignment crap. If
> David> we can avoid drivers seeing it, we should by all means
> David> necessary.
>
> David> We should just tell people to use PCI pools and be done
> David> with it. That way all the complexity about buffer
> David> alignment and all this other crapola lives strictly inside
> David> of the PCI pool code.
>
> That's fine but there are drivers (USB, etc) doing
>
> struct something {
> int field1;
> char dma_buffer[SMALLER_THAN_CACHE_LINE];
> int field2;
> };
>
> struct something *dev = kmalloc(sizeof *dev, GFP_KERNEL);
>
> Do they have to change to
>
> struct something {
> int field1;
> char *dma_buffer;
> int field2;
> };
>
> struct something *dev = kmalloc(sizeof *dev, GFP_KERNEL);
> dev->dma_buffer = kmalloc(SMALLER_THAN_CACHE_LINE, GFP_KERNEL);
>
> (This is always safe because as you said kmalloc can never return a
> slab that's not safe for DMA) I don't see how PCI pools help here.
In the USB case, the "something" represents a device, and the "dma_buffer" is
something you want to send-to / receive-from the device.
kmallocing the transfer buffers is a problem for suspend. Doing the "you get
the transfer buffer with the device" is really useful, because you know that
the device configuration will be returned. But we might need to re-init the
device after a suspend, and [I've been told that] memory allocation may
deadlock under these circumstances.
Would it be enought to move the transfer buffers to the start of the device
struct, and then pad it up to a cacheline?
-- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. - 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 : Sat Jun 15 2002 - 22:00:20 EST