LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Oliver Neukum <oliver@neukum.org>
To: linux-usb-devel@lists.sourceforge.net
Cc: Greg KH <greg@kroah.com>, Yinghai Lu <yhlu.kernel@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <ak@suse.de>
Subject: Re: [linux-usb-devel] [PATCH 3/4] usb: allocated usb releated dma buffer with	kmalloc_node
Date: Tue, 3 Jul 2007 08:23:07 +0200	[thread overview]
Message-ID: <200707030823.07815.oliver@neukum.org> (raw)
In-Reply-To: <20070703060155.GB19086@kroah.com>

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@kroah.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

  reply	other threads:[~2007-07-03  6:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-29 20:26 [PATCH 1/2] x86_64: get mp_bus_to_node as early Yinghai Lu
2007-07-02 22:34 ` [PATCH 1/4] usb: make the usb_device numa_node to get assigned from controller Yinghai Lu
2007-07-02 22:34 ` [PATCH 2/4] dma: make dma pool to use kmalloc_node Yinghai Lu
2007-07-02 22:36 ` [PATCH 3/4] usb: allocated usb releated dma buffer with kmalloc_node Yinghai Lu
2007-07-03  5:11   ` Greg KH
2007-07-03  5:33     ` Yinghai Lu
2007-07-03  6:01       ` Greg KH
2007-07-03  6:23         ` Oliver Neukum [this message]
2007-07-03  7:03           ` [linux-usb-devel] [PATCH 3/4] usb: allocated usb releated dma buffer with?kmalloc_node Greg KH
2007-07-03  7:12             ` Oliver Neukum
2007-07-04  6:08         ` [PATCH 3/4] usb: allocated usb releated dma buffer with kmalloc_node Yinghai Lu
2007-07-04  0:35     ` [PATCH 4/4] " Yinghai Lu
2007-07-02 22:37 ` [PATCH 4/4] net: add usb_alloc_urb_node to use use kmalloc_node Yinghai Lu
2007-07-03  5:13   ` Greg KH
2007-07-03  5:17     ` Yinghai Lu
2007-07-03  5:22       ` Roland Dreier
2007-07-03  5:59       ` Greg KH
2007-07-04  6:12         ` Yinghai Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200707030823.07815.oliver@neukum.org \
    --to=oliver@neukum.org \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=yhlu.kernel@gmail.com \
    --subject='Re: [linux-usb-devel] [PATCH 3/4] usb: allocated usb releated dma buffer with	kmalloc_node' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).