Re: [PATCH] irqchip: gic-v3: Collection table support muti pages

[Marc Zyngier <maz@kernel.org>]

On Tue, 16 May 2023 03:53:06 +0100,
wangwudi <wangwudi@hisilicon.com> wrote:
> 
> 
> 
> 在 2023/5/16 9:57, wangwudi 写道:
> > 
> > 
> > -----邮件原件-----
> > 发件人: Marc Zyngier [mailto:maz@kernel.org] 
> > 发送时间: 2023年5月15日 20:45
> > 收件人: wangwudi <wangwudi@hisilicon.com>
> > 抄送: linux-kernel@vger.kernel.org; Thomas Gleixner <tglx@linutronix.de>
> > 主题: Re: [PATCH] irqchip: gic-v3: Collection table support muti pages
> > 
> > On Mon, 15 May 2023 13:10:04 +0100,
> > wangwudi <wangwudi@hisilicon.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.

You're stating the obvious. My question was whether we were anywhere
close to that limit on any existing, or even planned HW.

> It is noticed by code review, not by on actual HW.

Right. So let me repeat my question: do you of any existing or planned
implementation that is both:

- using a small ITS page size
- having large per-collection memory requirements
- with a potentially large number of CPUs

that would result in CPUs not fitting in the collection table?

Assuming this is the case, is the CPU numbering space so large and
potentially sparse that it would benefit from 2 level tables instead
of a larger single-level table?

Finally, assuming all the above conditions are satisfied, what
actually populates the second level table in your patch? I don't see
anything that does. Which makes me think that it was never properly
tested.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.