Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 2 Jan 2002 04:27:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 2 Jan 2002 04:27:46 -0500 Received: from mailrelay1.lrz-muenchen.de ([129.187.254.101]:35953 "EHLO mailrelay1.lrz-muenchen.de") by vger.kernel.org with ESMTP id ; Wed, 2 Jan 2002 04:27:31 -0500 Date: Wed, 2 Jan 2002 10:27:11 +0100 (MET) From: X-X-Sender: To: David Brownell cc: Matthew Dharm , Jens Axboe , , , Greg KH Subject: Re: [linux-usb-devel] Re: highmem and usb [was:"sr: unalignedtransfer" in 2.5.2-pre1] In-Reply-To: <06df01c1934f$ee4e68a0$6800000a@brownell.org> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > > I presume there is some overhead in bouncing to lowmem? I imagine that > > highmem support for the HCDs wouldn't be that difficult -- they are just > > PCI devices, after all. > > I'm unclear on what "bouncing to lowmem" involves, but I'd rather avoid > teaching all three HCDs a second model for addressing transfer buffers. AFAIK bouncing means a plain, physical copy. Either the HCDs can do 64bit DMA or they can't. Do you really expect there to be a significant number of 32bit machines whose HCD can do 64bit DMA ? If not, it's IMHO not worth doing it as you'd have either two kinds of urbs or overhead in the common case. On 64Bit machines we might have to deal with HCDs who can do 32Bit DMA only. Perhaps there should be a gfp field in the usb_device struct to export knowledge about the memory the HCD can cope with. > > I'd rather eliminate as much overhead as possible -- I already get > > complaints from performance fanatics about the inability of usb-storage to > > get past 92% bus saturation (sustained), and the problem will only get > > worse on USB 2.0 > > Well then you'll be glad to see a patch from me, soonish, that teaches > the usb-storage "transport" code to use bulk queueing. That'll get the > bandwidth utilization up as high as it can get. It won't address any of > these highmem issues though. And there's the overhead of sleeping and waking a kernel thread. Larger io requests might help, but I am not sure. Regards Oliver - 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/