From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76654C77B7A for ; Tue, 16 May 2023 07:16:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230501AbjEPHQr (ORCPT ); Tue, 16 May 2023 03:16:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229875AbjEPHQp (ORCPT ); Tue, 16 May 2023 03:16:45 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 348B91BF7 for ; Tue, 16 May 2023 00:16:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BDC2763567 for ; Tue, 16 May 2023 07:16:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28FAAC433EF; Tue, 16 May 2023 07:16:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684221402; bh=8PLIXGq0nxO8jWho4OEmobicby5oXUWx3+A3Zdb6Hoo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ErzUhtpGb2sXv6kMyCfSAGOqYS10o5/FIbyjBs9cg1hcESA/Dbs469hhnk+czvKAY Bizgq2dKfc+dvGexXWtU++p0/LuI6d5McNccvi/Tglq919/N2Tsx4N0e8jbMHIrV+d 6YyubDUeGcRkQRDLU1ESriL8EZ+b3vKatdgffS5zSVu95a1ttGfTZlfCXgsDYSzB86 GWqeSZ2mzaWL5B/ZpIWALZ4TSTL6Ryy9NcEPG54OpsF8O9BuBJdTLTSOjl8UH5IHcS fp2I1LknKRDaXWuCEkF9aknbVTszrDfiRDq77QABFofALRGP0KQZ466/7GbgI1GPHo oxZgp7mT63Edg== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pyovH-00FRns-Q0; Tue, 16 May 2023 08:16:40 +0100 Date: Tue, 16 May 2023 08:16:19 +0100 Message-ID: <87cz30wxto.wl-maz@kernel.org> From: Marc Zyngier To: wangwudi Cc: , Thomas Gleixner Subject: Re: [PATCH] irqchip: gic-v3: Collection table support muti pages In-Reply-To: <5e42a892-3826-6370-9702-fefee88bf339@hisilicon.com> References: <1684152604-12621-1-git-send-email-wangwudi@hisilicon.com> <86jzx9n4qg.wl-maz@kernel.org> <41cbc6cb4e964fe0bbba87f52110b1c3@hisilicon.com> <5e42a892-3826-6370-9702-fefee88bf339@hisilicon.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: wangwudi@hisilicon.com, linux-kernel@vger.kernel.org, tglx@linutronix.de X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 16 May 2023 03:53:06 +0100, wangwudi wrote: >=20 >=20 >=20 > =E5=9C=A8 2023/5/16 9:57, wangwudi =E5=86=99=E9=81=93: > >=20 > >=20 > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Marc Zyngier [mailto:maz@kernel.org]=20 > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2023=E5=B9=B45=E6=9C=8815=E6=97= =A5 20:45 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: wangwudi > > =E6=8A=84=E9=80=81: linux-kernel@vger.kernel.org; Thomas Gleixner > > =E4=B8=BB=E9=A2=98: Re: [PATCH] irqchip: gic-v3: Collection table suppo= rt muti pages > >=20 > > On Mon, 15 May 2023 13:10:04 +0100, > > wangwudi wrote: > >> > >> Only one page is allocated to the collection table. > >> Recalculate the page number of collection table based on the number of= =20 > >> CPUs. > >=20 > > 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? >=20 > 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. >=20 > 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. --=20 Without deviation from the norm, progress is not possible.