Mark Lord wrote:
Jeff Garzik wrote:
Unless you have a _lot_ of ports active at the same time, irq
coalescing can increase latency.
I agree, which is why I haven't actually turned it on yet.
But a runtime sysfs attr for it should allow us to benchmark
things, and see if it really helps or not under various loads.
Ideally, for this, AHCI, and any other SATA controller that does
coalescing, we have a runtime dynamic trigger that turns on coalescing
when interrupt traffic exceeds a runtime limit.
Yeah, if coalescing turns out to be a win under hight load,
then a generic strategy like that would be a great feature.
It should definitely be a win. Every irq raised by the system, even
with MSI, has a fixed overhead, with spinlocks being taken along the way
or disable/enable_irq() deep in the system irq handler code. Its a
measurable CPU usage win reducing that overhead, if nothing else.
I've already "been there, done that" in the networking area, which
benefits from hardware (coalescing) and software (polling) interrupt
mitigation. Hardware miti mitigates interrupts on a per-hardware basis,
but doesn't have any inherent overall-system-load feedback mechanisms.
Software miti takes into account overall system load, but can be
somewhat dumb at times (can add overhead at low loads). However, "high
load" in networking easily means 10x or 100x the number of interrupts
per second. Networking also processes data in smaller chunks (== more
interrupt events). SATA is catching up though, at 3.0Gbps+ and 8-port
cards.
Jeff
-
: 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
