Re: linux/libata.h/ata_busy_wait() inefficiencies?

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> > Those two tweaks alone may already be able to deliver a noticeable speedup
> > of ata operations given that this is frequently used inner libata code.
> ..

Unlikely given the fact that chk_status will be a synchronous I/O request
across the bus and on many controllers across to the device itself. Any
other optimisations get a bit irrelevant

> While you're at it, the udelay(10) should really be *much* smaller,
> or at least broken into a top/bottom pair of udelay(5).  I really suspect
> that much of the time, the status value is satisified on the first iteration,
> requiring no more than a microsecond or so.  Yet we always force it to take
> at least 10us, or about 15000 instructions worth on a modern CPU.

That depends how long after the event before the wait_for_ is called
must elapse before the status bits are valid. There is also a trade off
of bus usage - especially on older devices where we will lock the bus and
thus CPU for maybe 1-2uS *per* chk_status.

If you want performance get an AHCI controller 8)

Alan