linux-kernel - About threaded interrupt handler CPU affinity

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-next>] [day] [month] [year] [list]

Date:   Mon, 22 Jul 2019 15:14:26 +0100
From:   John Garry <john.garry@...wei.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     <bigeasy@...utronix.de>, <maz@...nel.org>,
        chenxiang <chenxiang66@...ilicon.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: About threaded interrupt handler CPU affinity

Hi Thomas,

I have a question on commit cbf8699996a6 ("genirq: Let irq thread follow 
the effective hard irq affinity"), if you could kindly check:

Here we set the thread affinity to be the same as the hard interrupt 
affinity. For an arm64 system with GIC ITS, this will be a single CPU, 
the lowest in the interrupt affinity mask. So, in this case, effectively 
the thread will be bound to a single CPU. I think APIC is the same for this.

The commit message describes the problem that we solve here is that the 
thread may become affine to a different CPU to the hard interrupt - does 
it mean that the thread CPU mask could not cover that of the hard 
interrupt? I couldn't follow the reason.

We have experimented with fixing the thread mask to be the same as the 
interrupt mask (we're using managed interrupts), like before, and get a 
significant performance boost at high IO datarates on our storage 
controller - like ~11%.

Thanks in advance,
John