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: <20140924130444.GA16555@htj.dyndns.org>
Date:	Wed, 24 Sep 2014 09:04:44 -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 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-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/