[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5e42a892-3826-6370-9702-fefee88bf339@hisilicon.com>
Date: Tue, 16 May 2023 10:53:06 +0800
From: wangwudi <wangwudi@...ilicon.com>
To: Marc Zyngier <maz@...nel.org>
CC: <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] irqchip: gic-v3: Collection table support muti pages
在 2023/5/16 9:57, wangwudi 写道:
>
>
> -----邮件原件-----
> 发件人: Marc Zyngier [mailto:maz@...nel.org]
> 发送时间: 2023年5月15日 20:45
> 收件人: wangwudi <wangwudi@...ilicon.com>
> 抄送: linux-kernel@...r.kernel.org; Thomas Gleixner <tglx@...utronix.de>
> 主题: Re: [PATCH] irqchip: gic-v3: Collection table support muti pages
>
> On Mon, 15 May 2023 13:10:04 +0100,
> wangwudi <wangwudi@...ilicon.com> wrote:
>>
>> Only one page is allocated to the collection table.
>> Recalculate the page number of collection table based on the number of
>> CPUs.
>
> Please document *why* we should even consider this. Do you know of any existing implementation that is so large (or need so much memory for its collection) that it would result in overflowing the collection table?
Each CPU occupies an entry in the collection table. When there are a large number of CPUs and only one page of the collection table, some CPUs fail to execute ITS-MAPC cmd, and fail to receive LPI interrupts.
For example, GITS_BASER indicates that the page_size of the collection table is 4 KB, the entry size is 16 Bytes, and only 256 entries can be stored on one page.
When the number of CPUs is more than 256(which is common in the SMP system of the server), the subsequent CPUs cannot receive the LPI.
It is noticed by code review, not by on actual HW.
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists