> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
