Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 13 Jun 2002 00:56:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 13 Jun 2002 00:56:36 -0400 Received: from mta5.snfc21.pbi.net ([206.13.28.241]:28341 "EHLO mta5.snfc21.pbi.net") by vger.kernel.org with ESMTP id ; Thu, 13 Jun 2002 00:56:36 -0400 Date: Wed, 12 Jun 2002 21:57:52 -0700 From: David Brownell Subject: Re: PCI DMA to small buffers on cache-incoherent arch To: Oliver Neukum Cc: linux-kernel@vger.kernel.org, linux-usb-devel@lists.sourceforge.net Message-id: <3D082650.6020702@pacbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en, fr User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 In-Reply-To: <20020611.202553.28822742.davem@redhat.com> <52zny049r7.fsf@topspin.com> <3D079D44.4000701@pacbell.net> <200206122158.55375.oliver@neukum.name> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >>That'd certainly be a better approach for supporting sglist in the >>usb-storage code than the alternatives I've heard so far. > > Could you elaborate ? This sounds interesting. It's been discussed on linux-usb-devel more than once. It's really a secondary or tertiary consideration. The top performance issue for usb-storage in USB 2.0 is that it doesn't yet use bulk queueing for its requests ... which means that it wastes at least half the bandwidth available to it (staying in the low tens of MByte/sec vs twenties or even higher). [*] The sglist issue is a "how to create fewer DMA mappings" issue. There are specific sglist DMA mapping calls, but they can't be used without adding to the usbcore API ... either sglist, usable only by usb-storage AFAICT, or something more general like dma_addr_t. In any case it's an optimization issue that doesn't seem like it should be at the front of anyone's list for some time. - Dave [*] Yes, patches have been available to fix it. Not updated after the block I/O changes in 2.5, but not hard to do so. Worth updating and integrating after the HCD stuff settles down so we can make sure that all three major HCDs do the bulk queuing correctly in both success and failure paths. - 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/