On Apr 11, 2007, at 1:26 AM, Dmitri Epshtein wrote:

> 1. We don't use FAT filesystem, but 4.2BSD
> 2. We are running on ARM, but USB buffers looks like cached ones
> See in the function usb_block_allocmem() file usb_mem.c
> 	error = bus_dmamem_map(tag, p->segs, p->nsegs, p->size,
> 			       &p->kaddr, BUS_DMA_NOWAIT |
> BUS_DMA_COHERENT);

On ARM, BUS_DMA_COHERENT gives you uncached mappings.

> I do system profile and see that cpu spend more than 20% of time in  
> the
> memcpy function (see umass.c)
> while coping all USB data between two kernel buffers and additional 8%
> in memset function.
>
> I am intresting if somebody tried to skip this copy.

I am to understand that kkipping that copy requires the USB stack  
overhaul that was initially discussed in this thread.

>
> Thanks
> Dima
>
> -----Original Message-----
> From: Steve Woodford [mailto:scw@netbsd.org]
> Sent: Friday, March 30, 2007 12:26 PM
> To: Dmitri Epshtein
> Cc: tech-kern@netbsd.org
> Subject: Re: USB stack needs early review (Re: Someone should fix our
>
> On Thursday 29 March 2007 16:07, Dmitri Epshtein wrote:
>
>> I am trying to understand why USB performance of mass storage device
>> is bad.
>> I mounted attached USB disk as /mnt/disk and run simple 'dd' command
>> to read and write data to disk
>> => dd if=/dev/zero of=/mnt/disk/new_file2 bs=131072 count=8196   //
>> write
>> => dd of=/dev/zero if=/mnt/disk/1G_file bs=131072 count=8196     //
>> read
>
> I can think of two reasons for this:
>
> 1. If your USB disk contains a FAT filesystem, be aware that NetBSD's
>    FAT support does not perform read/write clustering. This results in
>    lots of small USB packets, thus under-utilising the available
>    bandwidth.
> 2. If you're running on ARM, the USB buffers are all cache-inhibited.
>    I shouldn't need to tell you how much that will hurt  
> performance. ;)
>
> It looks like there are moves afoot to fix #2 by importing changes  
> from
> FreeBSD, but I'm not aware of any plans to fix #1.
>
> Cheers, Steve

-- thorpej