Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [PATCH v2 0/3] genirq: Managed affinity fixes
To:     Marc Zyngier <maz@kernel.org>
CC:     linux-kernel <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        John Garry <john.garry@huawei.com>,
        David Decotigny <ddecotig@google.com>
References: <20220321193608.975495-1-maz@kernel.org>
 <a83da394-dcc0-c9a6-1569-9c30fbc291fd@huawei.com>
 <87a6dhxd13.wl-maz@kernel.org>
From:   Xiongfeng Wang <wangxiongfeng2@huawei.com>
Message-ID: <d7019731-4ade-ea79-7464-f52872a60d79@huawei.com>
Date:   Wed, 23 Mar 2022 18:58:33 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <87a6dhxd13.wl-maz@kernel.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2022/3/23 16:56, Marc Zyngier wrote:
> Hi Xiongfeng,
> 
> On Wed, 23 Mar 2022 03:52:46 +0000,
> Xiongfeng Wang <wangxiongfeng2@huawei.com> wrote:
>>
>> Hi, Marc
>>
>> On 2022/3/22 3:36, Marc Zyngier wrote:
>>> John (and later on David) reported[1] a while ago that booting with
>>> maxcpus=1, managed affinity devices would fail to get the interrupts
>>> that were associated with offlined CPUs.
>>>
>>> Similarly, Xiongfeng reported[2] that the GICv3 ITS would sometime use
>>> non-housekeeping CPUs instead of the affinity that was passed down as
>>> a parameter.
>>>
>>> [1] can be fixed by not trying to activate these interrupts if no CPU
>>> that can satisfy the affinity is present (a patch addressing this was
>>> already posted[3])
>>>
>>> [2] is a consequence of affinities containing non-online CPUs being
>>> passed down to the interrupt controller driver and the ITS driver
>>> trying to paper over that by ignoring the affinity parameter and doing
>>> its own (stupid) thing. It would be better to (a) get the core code to
>>> remove the offline CPUs from the affinity mask at all times, and (b)
>>> fix the drivers so that they can trust the core code not to trip them.
>>>
>>> This small series, based on 5.17, addresses the above.
>>
>> I have tested this patchset on D06. It works well with kernel parameter
>> 'maxcpus=1' or 'nohz_full=1-127 isolcpus=nohz,domain,managed_irq,1-127'.
>> Also the 'effective_affinity' is correct. Thanks!
> 
> Thanks for having given it a go.
> 
>> By the way, I merged the second patch manually because of conflicts.
>> Maybe I lack some patches on your local repo.
> 
> That's odd, as the patches are directly sitting on top of 5.17 in my
> tree (see [1]). Do you have any out of tree patches around? Please
> make sure you test this without any extra change.

I apply the patchset based on the latest mainline kernel. The latest commit is
  commit 3bf03b9a0839c9fb06927ae53ebd0f960b19d408
  Merge branch 'akpm' (patches from Andrew)
I didn't change the modification of the second patch. Only resolve the
context conflicts, which is cause by the following commit.
  commit 04d4e665a60902cf36e7ad39af1179cb5df542ad
  sched/isolation: Use single feature type while referring to housekeeping cpumask
It changed 'HK_FLAG_MANAGED_IRQ' to 'HK_TYPE_MANAGED_IRQ'.

Thanks,
Xiongfeng

> 
> Thanks,
> 
> 	M.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/managed-affinity-fixes
>