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 =3D bus_dmamem_map(tag, p->segs, p->nsegs, p->size,
			       &p->kaddr, BUS_DMA_NOWAIT |
BUS_DMA_COHERENT);=20

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.

Thanks
Dima

-----Original Message-----
From: Steve Woodford [mailto:scw@netbsd.org]=20
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
> =3D> dd if=3D/dev/zero of=3D/mnt/disk/new_file2 bs=3D131072 =
count=3D8196   //
> write
> =3D> dd of=3D/dev/zero if=3D/mnt/disk/1G_file bs=3D131072 count=3D8196 =
    //
> 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=20
FreeBSD, but I'm not aware of any plans to fix #1.

Cheers, Steve