linux-kernel - Re: Affinity managed interrupts vs non-managed interrupts

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: <alpine.DEB.2.21.1809061244151.1570@nanos.tec.linutronix.de>
Date:   Thu, 6 Sep 2018 13:46:46 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Dou Liyang <dou_liyang@....com>
cc:     Kashyap Desai <kashyap.desai@...adcom.com>,
        Ming Lei <tom.leiming@...il.com>,
        Sumit Saxena <sumit.saxena@...adcom.com>,
        Ming Lei <ming.lei@...hat.com>, Christoph Hellwig <hch@....de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Shivasharan Srikanteshwara 
        <shivasharan.srikanteshwara@...adcom.com>,
        linux-block <linux-block@...r.kernel.org>,
        Dou Liyang <douly.fnst@...fujitsu.com>
Subject: Re: Affinity managed interrupts vs non-managed interrupts

On Thu, 6 Sep 2018, Dou Liyang wrote:
> At 09/05/2018 06:38 PM, Thomas Gleixner wrote:
> > Oh well. This was not intended to magically provide the solution you want
> > to have. It merily changed the behaviour of the managed interrupt
> > selection, which is a valid thing to do independent of the stuff you want
> > to see.
> > 
> 
> Thank you for clarifying it, I will send the patch independently.
> 
> > As I said that needs more thought and I really can't tell when I have a
> > time slot to look at that.
> > 
> 
> In this period, I am willing to be a volunteer to try to do that you
> said in the previous reply. May I?

You don't have to ask for permission. It's Open Source :)

There are a few things we need to clarify upfront:

Right now the pre and post vectors are marked managed and their
affinity mask is set to the irq default affinity mask.

The default affinity mask is by default ALL cpus, but it can be tweaked
both on the kernel command line and via proc.

If that mask is only a subset of CPUs and all of them go offline
then these vectors are shutdown in managed mode.

That means we need to set the affinity mask of the pre and post vectors to
possible mask, but that doesn't make much sense either, unless there is a
reason to have them marked managed.

I think the right solution for these pre/post vectors is to _NOT_ mark
them managed and leave them as regular interrupts which can be affinity
controlled and also can move freely on hotplug.

Christoph?

Thanks,

	Thomas