Re: [PATCH 2.6.34] ehci-hcd: add option to enable 64-bit DMA support

[Greg KH <greg@kroah.com>]

On Thu, Feb 18, 2010 at 06:33:42PM -0600, Robert Hancock wrote:
> On Wed, Feb 17, 2010 at 11:22 PM, Greg KH <greg@kroah.com> wrote:
> > On Wed, Feb 17, 2010 at 11:13:05PM -0600, Robert Hancock wrote:
> >> On Wed, Feb 17, 2010 at 10:26 PM, Greg KH <greg@kroah.com> wrote:
> >> > On Wed, Feb 17, 2010 at 09:10:13PM -0600, Robert Hancock wrote:
> >> >> Add a module parameter to allow the user to enable 64-bit DMA support in EHCI,
> >> >> which has been forcibly disabled since 2003 - see:
> >> >>
> >> >> http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg17230.html
> >> >>
> >> >> At that time the comment was "it'd only matter on a few big Intel boxes anyway",
> >> >> however the situation is much different today when many new machines have 4GB
> >> >> or more of RAM and IOMMU/SWIOTLB are thus needlessly required for USB transfers.
> >> >> For now, the support remains disabled by default and is controlled by an
> >> >> allow_64bit module parameter.
> >> >>
> >> >> Note that some USB device drivers may require updates to pass the DMA
> >> >> capabilities up to their higher layers to avoid unnecessary IOMMU or bounce-
> >> >> buffer use (i.e. networking layer NETIF_F_HIGHDMA). Some of these checks were
> >> >> disabled by the patch listed above, and more may be required again today.
> >> >> However, those previous checks were done incorrectly using dma_supported,
> >> >> which checks to see whether a device's DMA mask can be validly set to a given
> >> >> mask, not whether its previously set mask will accomodate the mask passed in.
> >> >>
> >> >> Signed-off-by: Robert Hancock <hancockrwd@gmail.com>
> >> >
> >> > What is the "advantage" that setting this option would allow people to
> >> > do that the code currently does not? ?Is such an advantage measurable at
> >> > the slow rates that the EHCI driver controls?
> >>
> >> I expect it would likely be quite system-dependent. However,
> >> particularly with devices like high-speed USB storage on systems with
> >> lots of RAM, especially 8GB or more (where more of the memory can't be
> >> addressed with 32-bit than can), I suspect it would likely be
> >> measurable in terms of CPU usage, throughput or both, especially if
> >> there's no hardware IOMMU and software bounce-buffering is required.
> >
> > So you did not measure it?
> >
> > Hm, I guess this change must not be necessary :)
> 
> I'll try and run some tests and see what I can quantify. However, I
> only have 4GB of RAM on my machine (with a 1GB memory hole) and so a
> random memory allocation only has a 25% chance of ending up in the
> area where it would make a difference, so it may take a bit of doing.

Without any good justification, including real tests being run, I can't
take this patch, the risk is just too high.

And really, for USB 2.0 speeds, I doubt you are going to even notice
this kind of overhead, it's in the noise.  Especially given that almost
always the limiting factor is the device itself, not the host.

thanks,

greg k-h