Eliminating rwlocks and IRQF_DISABLED

Posted Dec 4, 2009 5:05 UTC (Fri) by naptastic (guest, #60139)
Parent article: Eliminating rwlocks and IRQF_DISABLED

I don't understand how disabling interrupts during interrupt handlers is a good thing. I can see the increase in throughput because there's one less context switch, but isn't the added latency from non-interruptible interrupt handlers much worse?

It's frustrating for someone like me to watch these decisions keep getting made in favor of throughput (which you could get just as easily by overclocking your processor another half percent) and at the expense of latency, which seems to never go down, especially when the costs and benefits are so lopsided.

Eliminating rwlocks and IRQF_DISABLED

Posted Dec 4, 2009 14:19 UTC (Fri) by corbet (editor, #1) [Link] (2 responses)

Bear in mind that much of this work is being done by the principal developers behind the realtime preemption tree. I suspect that they're uninterested in increasing latencies...

Eliminating rwlocks and IRQF_DISABLED

Posted Dec 4, 2009 18:49 UTC (Fri) by naptastic (guest, #60139) [Link] (1 responses)

Yeah... what are they seeing that I'm not?

Eliminating rwlocks and IRQF_DISABLED

Posted Dec 5, 2009 23:51 UTC (Sat) by smipi1 (subscriber, #57041) [Link]

Provided interrupt handlers do nothing more than the absolute minimum in
interrupt context, this approach will not adversely affect latencies.

Allowing interrupt handlers to be interrupted actually is far worse: It
introduces context switching overhead and screws up overall predictability.

If all interrupt handlers simply feed threads (that actually do the
associated work) without interruption, latencies can be tuned by design and
not by accident. Balancing throughput and latency simply becomes a question
of educating your scheduler.