Re: [PATCH 2/7] sata_mv: deal with interrupt coalescing interrupts

[Jeff Garzik <jgarzik@pobox.com>]

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