Re: speeding up ugen by an order of magnitude.

From: Bernd Walter <ticso_at_cicely12.cicely.de>
Date: Wed, 7 Jul 2004 11:59:50 +0200
On Wed, Jul 07, 2004 at 11:16:14AM +0200, Poul-Henning Kamp wrote:
> In message <20040707091311.GE12877_at_cicely12.cicely.de>, Bernd Walter writes:
> >On Tue, Jul 06, 2004 at 04:32:28PM -0700, Julian Elischer wrote:
> 
> >What about those options:
> >- limit the allocated memory to the user request so we don't take the
> >  whole 128k if not reuired.
> >- Do interleaving with 2 or more xfers if the read request is known to
> >  take more xfers.
> 
> I would consider ugen to be a primary candidate to use physio like
> I belive scsi-tape drives do ?

I don't really know the points between physio and the current way.
The story with USB bulk transfers is that legal transfers can have a
data size of even down to 0 bytes and a lot a typical clients do
small transfers - just depends on the designers needs.
In the current code it seems that short transfers are already broken
at least I don't see where short transfers can break out of the while
loop so the knowledge about the real transfers size is lost.
Under normal conditions we should break out on short transfers and
return the so far transfered size.
We should also be able to do interleaving some day.
If you think that the requirements wouldn't collide with physio then
OK.

Nevertheless I see ugen more as a quick and dirty way to test drive a
device from userland with all it's great debugging capabilities before
writing a specific kernel driver.
The requirement that ugen has to be generic is often bad for
performance sensitive applications.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd_at_bwct.de                                  info_at_bwct.de
Received on Wed Jul 07 2004 - 08:00:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:00 UTC