linux-kernel - Re: [PATCH v2] irqchip/gic-v3-its: Balance initial LPI affinity across CPUs

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]

Date:   Thu, 12 Mar 2020 15:56:14 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     John Garry <john.garry@...wei.com>
Cc:     linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Ming Lei <ming.lei@...hat.com>,
        chenxiang <chenxiang66@...ilicon.com>,
        Zhou Wang <wangzhou1@...ilicon.com>
Subject: Re: [PATCH v2] irqchip/gic-v3-its: Balance initial LPI affinity
 across CPUs

Hi John,

On 2020-03-12 15:41, John Garry wrote:
> On 12/03/2020 11:55, Marc Zyngier wrote:
> 
> Hi Marc,
> 
>> When mapping a LPI, the ITS driver picks the first possible
>> affinity, which is in most cases CPU0, assuming that if
>> that's not suitable, someone will come and set the affinity
>> to something more interesting.
>> 
>> It apparently isn't the case, and people complain of poor
>> performance when many interrupts are glued to the same CPU.
>> So let's place the interrupts by finding the "least loaded"
>> CPU (that is, the one that has the fewer LPIs mapped to it).
>> So called 'managed' interrupts are an interesting case where
>> the affinity is actually dictated by the kernel itself, and
>> we should honor this.
>> 
>> Reported-by: John Garry <john.garry@...wei.com>
>> Link: 
>> https://lore.kernel.org/r/1575642904-58295-1-git-send-email-john.garry@huawei.com
>> Signed-off-by: Marc Zyngier <maz@...nel.org>
>> Cc: John Garry <john.garry@...wei.com>
>> Cc: Ming Lei <ming.lei@...hat.com>
>> ---
>> Reviving this at John's request.
> 
> Thanks very much. I may request a colleague test this due to possible
> precautionary office closure.

Huh. Not great... :-(

> 
>  The major change is that the
>> affinity follows the x86 model, as described by Thomas.
> 
> There seems to be a subtle difference between this implementation and
> what Thomas described for managed interrupts handling on x86. That
> being, managed interrupt loading is counted separately to total
> interrupts per CPU for x86. That seems quite important so that we
> spread managed interrupts evenly.

Hmmm. Yes. That'd require a separate per-CPU counter. Nothing too 
invasive
though. I'll roll that in soon. I still wonder about interaction of 
collocated
managed and non-managed interrupts, but we can cross that bridge later.

>> I expect this to have an impact on platforms like D05, where
>> the SAS driver cannot use managed affinity just yet.
> 
> I need some blk-mq and SCSI changes to go in first to improve the
> interrupt handling there, hopefully we can make progress on that soon.

That'd be good.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...