Mark Lord writes: > Tejun Heo wrote: > >.. > > I'm skeptical about the benefit of IRQ coalescing on storage > > controllers. Coalescing improves performance when there are many small > > requests to complete and if you put a lot of small non-consecutive > > requests to a disk, it gets really really really slow and IRQ coalescing > > just doesn't matter at all. The only way to achieve high number of > > completions is to issue small commands to consecutive addresses which is > > just silly. In storage, high volume transfer is achieved through > > request coalescing not completion coalescing and this is true for even SDDs. > .. > > One cool thing with the Marvell cores, is that they actually implement > "transaction based" IRQ coalescing, whereby a number of related I/O commands > (say, all the RAID5 member commands generated by a single R/W request) > can be tagged together, generating an interrupt only when they all complete > (or after a timeout if something goes wrong). > > We don't have anything resembling an appropriate abstraction for that yet, > so I doubt that we could really take advantage of it. Promise SATA controllers have this feature too, though sata_promise doesn't make use of it. - 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
