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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200707030823.07815.oliver@neukum.org>
Date:	Tue, 3 Jul 2007 08:23:07 +0200
From:	Oliver Neukum <oliver@...kum.org>
To:	linux-usb-devel@...ts.sourceforge.net
Cc:	Greg KH <greg@...ah.com>, Yinghai Lu <yhlu.kernel@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <ak@...e.de>
Subject: Re: [linux-usb-devel] [PATCH 3/4] usb: allocated usb releated dma buffer with	kmalloc_node

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@...ah.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/