Hello, Alexander. On Wed, Sep 24, 2014 at 11:42:15AM +0100, Alexander Gordeev wrote: > On Tue, Sep 23, 2014 at 04:57:10PM -0400, Tejun Heo wrote: > > Hmmm... how does it affect single device operation tho? It does make > > individual interrupt handling heavier, no? > > I think it is difficult to assess "individual interrupt handling", since > it depends from both the hardware and device access pattern. On the system > I use the results are rather counter-intuitive: ahci_thread_fn() does not > show up in perf report at all, nor ahci_single_irq_intr(). While before > the change ahci_single_irq_intr() reported 0.00%. > > But since the handling is split in two parts it is rather incorrect to > apply the same metric to the threaded context. Obviously, the threaded > handler is expected slowed down by other interrupts handlers, but the > whole system should benefit from it, which is exactly the aim of this > change. Hmmm, how would the whole system benefit from it if there's only single device? Each individual servicing of the interrupt does more now which includes scheduling which may end up adding to completion latency. The thing I don't get is why multiple MSI handling and this patchset are tied to threaded interrupt handling. Splitting locks don't necessarily have much to do with threaded handling and it's not like ahci interrupt handling is heavy. The hot path is pretty short actually. The meat of the work - completing requests and propagating completions - is offloaded to softirq by block layer anyway. Just to be clear, I'm not against the proposed changes but wanna understand the justifications behind them. Thanks. -- tejun -- 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
