[haiku-development] Re: Slow Alpha Installation
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 10 Sep 2009 17:02:19
> Hi,
>
> On 2009-09-10 at 09:57:57 [+0000], Nicholas Otley <
> nicholasotley@xxxxxxxxx>
> wrote:
> > I did a test installation from the r33023 Alpha ISO to a USB pen
> > drive
> > and it took over 4 hours!
> >
> > I did it from within VMWare Fusion so I'm unsure of whether it is a
> > problem with Fusion or with Haiku yet.
> >
> > I'll try to do the same again but from real hardware later today
> > and
> > report back.
>
> I know I have a supposed to be very quick USB stick, which seems to
> be
> connected via USB 2.0 on my Haiku PC (native install) according to
> listusb.
> This stick is operating extremely slowly. I have not tried to write
> to it
> yet, but I suspect it would be even worse than reading. I didn't yet
> take
> the time to file a ticket, since I am just happy that it works at all
> ... ;-)
>
> Over time, I am sure we will figure out those issues.
I can pretty much tell you: The usb_disk driver doesn't support the IO
hook. The IO requests that are created as physical requests therefore
have to be made virtual to be fed to the normal read/write hooks. The
physical buffers are mapped to virtual ones, which sucks for two
reasons: Mapping involves a lot of locking/TLB flushing overhead and it
is done page wise. So any read/write from a device will be at max 4K in
size. And we know how well these devices usually perform for small
transfers...
The reason this hasn't been addressed is twofold. The usb_disk driver
uses the old driver architecture (because of simplicity and because the
USB stack isn't new style either) which makes the IO hook unavailable.
This could be solved by upping the driver API version and adding the
hook. The other problem is that the physical buffers can't be fed to
the USB stack as it operates purely on virtual addresses (per the v2
and v3 USB API coming from BeOS) and copies stuff into its own physical
buffers.
The steps to solve the problem: Introduce USB stack API to hand in
physical buffers, adapting the stack and drivers. Add IO hook to usb_
disk one way or another, add an IOScheduler there that splits up the IO
requests into handy packets that can then be fed into the new USB stack
API.
Right now I am working towards the alpha mostly, but in the background
I am already working on the steps mentioned above. I already have a
pretty clear picture on how to go forward with all of it and will
hopefully have something ready soon after the alpha.
Regards
Michael
Other related posts:
