linux-kernel - Re: [PATCH RESEND v3 5/6] AHCI: Optimize single IRQ interrupt processing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140924143913.GH16555@htj.dyndns.org>
Date:	Wed, 24 Sep 2014 10:39:13 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Alexander Gordeev <agordeev@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [PATCH RESEND v3 5/6] AHCI: Optimize single IRQ interrupt
 processing

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/