Re: [linux-usb-devel] [PATCH 3/4] usb: allocated usb releated dma buffer with kmalloc_node

From: Oliver Neukum
Date: Tue Jul 03 2007 - 02:23:19 EST


Am Dienstag, 3. Juli 2007 schrieb Greg KH:
> On Mon, Jul 02, 2007 at 10:33:12PM -0700, Yinghai Lu wrote:
> > On 7/2/07, Greg KH <greg@xxxxxxxxx> wrote:
> > > On Mon, Jul 02, 2007 at 03:36:37PM -0700, Yinghai Lu wrote:
> > > > [PATCH 3/4] usb: allocated usb releated dma buffer with kmalloc_node
> > > >
> > > > For amd64 based two way system. USB always on node0. but dma buffer for
> > > urb
> > > > allocated via kmalloc always get ram on node1. So change to kmalloc_node
> > > to
> > > > get dma_buffer on corresponding node
> > >
> > > Are all of these changes really necessary? You are doing this for some
> > > allocations that take a _long_ time when sending to the device due to
> > > the speed of the device.
> > >
> > > I could possibly see this making a difference on some drivers, but for
> > > the core, and for the basic USB structures, I can't imagine it is really
> > > worth it.
> > >
> > > Or do you have numbers showing the differences here?
> > >
> > > Patch included fully below for the benifit of the usb list, which you
> > > should have cc:ed...
> >
> > dma buffer could be allocated via alloc_pages_coherent. or
> > kmalloc/dma_map_single.
> > alloc_pages_coherent get the dma_buffer on corresponding node.
> > but kmalloc/dma_map_single always get dma_buffer on last node. or say
> > device is on HT chain node0, it will get dma buffer on node 7 of 8
> > socket system.
> > also on two way system with 4G+4G RAM conf. device on node 0 will get
> > dma_buffer above 4G, and if the dma_mask is less 32bit, will need
> > extra iommu mapping.
> > In my mcp55+io55 system, it show dma_map_single is keepping called by
> > usb input: keyboard/mouse (8/0x40 bytes), and forcedeth. (0x670bytes)
>
> Ok, so two drivers might need this, but not the whole usb core, right?

If those two drivers need the extended allocator, why not use it where
it is beneficial, even if the benefit is small?

Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/