Hello, Alexander. On Wed, Sep 24, 2014 at 03:08:44PM +0100, Alexander Gordeev wrote: > > 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. > > As Chuck noticed, non-AHCI hardware context handlers will benefit. Maybe I'm off but I'm kinda skeptical that we'd be gaining back the overhead we pay by punting to a thread. > > The thing I don't get is why multiple MSI handling and this patchset > > are tied to threaded interrupt handling. > > Multiple MSIs were implemented with the above aim (let's say aim #1) > right away. Single MSI/IRQ handling is getting updated with this series. Yeah, I get that. I'm curious whether that was justified. > > 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. > > So the aim (let's say aim #2) is to avoid any of those to compete with > hardware context handler. IOW, not to wait on host/port spinlocks with > local interrupts disabled unnecessarily. > > I assume, if at the time of writing of original handlers the two > interrupt context existed, they were written the way I propose now :) Maybe it makes sense with many high speed devices attached to a single host; otherwise, I think we'd prolly be paying more than we're gaining. Lock splitting itself is likely beneficial as our issue path is a lot heavier than completion path but I'm not too sure about splitting completion contexts especially given that completion for block layer and up are already punted to softirq. Would it be possible for you compare threaded vs. unthreaded under relatively heavy load? ie. let the interrupt handler access irq status under host lock but release it and then go through per-port locks from the interrupt handler. Thanks for doing this! -- 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
