On 15-10-30 10:01 PM, Tejun Heo wrote:
On Fri, Oct 30, 2015 at 06:59:14PM -0700, Dan Williams wrote:
On Fri, Oct 30, 2015 at 5:56 PM, Tejun Heo <tj@xxxxxxxxxx> wrote:
On Fri, Oct 30, 2015 at 05:09:46PM -0400, Dan Williams wrote:
For high frequency I/O the overhead of threaded interrupts impacts
performance. Add an option to make it configurable, with the default
being hardirq.
A quick out-of-the-box test (i.e. no affinity tuning) shows ~10% random
read performance at ~20% less cpu. The cpu wins appear to be from
reduced lock contention.
Do we need threaded irq at all? Why not just switch to hardirq?
I can't imagine anyone doing high iops storage to also rely on the
ability to preempt the irq handler. I'm assuming if someone notices
it missing they can scream, but otherwise hardirq seems all around
better.
NVMe also has this optional via module parameter, but talking to Keith
he does not know of anyone using it.
Let's remove it for now and do the conditional thing if anybody misses
it. No need to keep around dead code proactively.
Aren't threaded IRQs there to improve overall system real-time response?
If so, it would seem a step backwards to remove them completely,
especially considering the low cost of maintaining them here.
Cheers
--
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
