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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3086CC30659 for ; Wed, 26 Jun 2024 08:42:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=gH93EfAE6nr0nQmu8VGrpsUbktQLVboZXN6viV9mic0=; b=vVztk229mh9iO9uA3fR0/vNn3F WHXdY0uOL1S7FlvtlthLgrh6cS9KjrgrB+RFWmz89iqJr+540660E8SQ4ZPBlWpWboOSYcFCsVAOZ Ua/TeZgG+jsXLFO5OtGhbijXCGlwiPWFMrd8udB8f1eKE5AfNPjbGz786c017GMasFFBjAtwiVklP 1nyBPTU0p8w1x5OMrp9RcsWKhLTlrkLaYTx8khiBq8Kv4wahdpB8yX8ljjxg7XnrsmSINq6aqgynC 407OgvFH3gREmpkhbdhlrkdltOzNZ3GCsEvGh6ow9rK8HQwNOhUpKSQOCYUTJTixr2i709XR7vQVA RR5d9DXQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sMOEL-00000005xnl-3WTS; Wed, 26 Jun 2024 08:42:17 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sMOEE-00000005xkS-2adL for linux-arm-kernel@lists.infradead.org; Wed, 26 Jun 2024 08:42:12 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 25619CE211F; Wed, 26 Jun 2024 08:42:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4724BC2BD10; Wed, 26 Jun 2024 08:42:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719391327; bh=S3cTJq0D8wadO/sI5sOPrvLtWcPVaif86bP86Z/8TBM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=u9+jzSnz8nuZ1+TyS61jUTAxDUGAsxVzcTciZgUhn/ug9xR6SS4y+Nw94lUTMIfOj gbYdVfDohtbC4VgoVkSG8WX0rnPfqtU1V3PSW/9vmv61RUswGXReEkMXwGEJQJjN7Y VYa6bYhamWAr5YbypZZLUpW7iLmciwVjzZUazYIBrb23F5vbl5XO0R33pu8GhO4R8o dgLrjFmAXyPuxkEn2vbfRRV2N2QGv9CKDAYPCwPqSAQ1kHv+cPzKKExnrAVbv+CRWM 3s3y4qky0dXqOdZyN8x/PDmQok0b3LfbblbVBInEtfdZyBtKW8+Dm3bkTdi6LBqh+S ov9W3MoVyOHWQ== Received: from [104.132.45.100] (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 1sMOE8-007Q72-TZ; Wed, 26 Jun 2024 09:42:05 +0100 Date: Wed, 26 Jun 2024 09:41:59 +0100 Message-ID: <87tthgrt7s.wl-maz@kernel.org> From: Marc Zyngier To: Tangnianyao Cc: , , , , Subject: Re: [RESEND PATCH] irqchip/gic-v4.1: Use the ITS of the NUMA node where current cpu is located In-Reply-To: <60de5bd6-51db-e327-5808-280407a6285d@huawei.com> References: <20240625014019.3914240-1-tangnianyao@huawei.com> <86wmmdihkf.wl-maz@kernel.org> <60de5bd6-51db-e327-5808-280407a6285d@huawei.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=US-ASCII X-SA-Exim-Connect-IP: 104.132.45.100 X-SA-Exim-Rcpt-To: tangnianyao@huawei.com, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, guoyang2@huawei.com, wangwudi@hisilicon.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240626_014211_041571_888FAC00 X-CRM114-Status: GOOD ( 57.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 26 Jun 2024 03:22:52 +0100, Tangnianyao wrote: > > > > On 6/25/2024 15:53, Marc Zyngier wrote: > > On Tue, 25 Jun 2024 02:40:19 +0100, > > Nianyao Tang wrote: > >> When GICv4.1 enabled, guest sending IPI use the last ITS reported. > >> On multi-NUMA environment with more than one ITS, it makes IPI performance > >> various from VM to VM, depending on which NUMA the VM is deployed on. > >> We can use closer ITS instead of the last ITS reported. > > Closer to *what*? the SGI sender? or the receiver? Something else? > > VSGI sender. > VSGI sender use original find_4_1_its to inject vsgi, it always find the last reported > 4_1 ITS, regardless of which NUMA the VSGI sender cpu is located on. So your concern is about cross-node MMIO accesses? You should capture this in your commit message. > > > > >> Modify find_4_1_its to find the ITS of the NUMA node where current > >> cpu is located and save it with per cpu variable. > > But find_4_1_its() isn't only used for SGIs. Is it valid to do this > > trick for all use cases? > > To consider this case, I've implemented original find_4_1_its function, finding a > 4_1 ITS in system and return, even NUMA is not match. Would it be enough to be > compatitable with other code ? That's not what I'm asking. The same helper is also used when invalidating a doorbell, configuring VSGIs, tearing down of a VPE. Do you see similar issues with these functionalities not a local ITS? Or is your issue specific to VSGI generation? > A new find_4_1_its can firstly select 4_1 ITS on the same NUMA as the current > cpu(VSGI sender), and if fail to find, then return 4_1 ITS on other NUMA. > > > > >> (There's format issues with the previous patch, resend it) > > In the future, please move this sort of comment to a note after the > > --- delimiter. > > ok, get it. > > > > >> Signed-off-by: Nianyao Tang > >> --- > >> drivers/irqchip/irq-gic-v3-its.c | 27 ++++++++++++++++++--------- > >> 1 file changed, 18 insertions(+), 9 deletions(-) > >> > >> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > >> index 3c755d5dad6e..d35b42f3b2af 100644 > >> --- a/drivers/irqchip/irq-gic-v3-its.c > >> +++ b/drivers/irqchip/irq-gic-v3-its.c > >> @@ -193,6 +193,8 @@ static DEFINE_RAW_SPINLOCK(vmovp_lock); > >> > >> static DEFINE_IDA(its_vpeid_ida); > >> > >> +static DEFINE_PER_CPU(struct its_node *, its_on_cpu); > > I don't really get the "its_on_cpu" name. "local_its" would at least > > indicate a notion being "close". > > I want to mean ITS on the current cpu NUMA node. > Yes, "local_its" is better. > > > > >> + > >> #define gic_data_rdist() (raw_cpu_ptr(gic_rdists->rdist)) > >> #define gic_data_rdist_cpu(cpu) (per_cpu_ptr(gic_rdists->rdist, cpu)) > >> #define gic_data_rdist_rd_base() (gic_data_rdist()->rd_base) > >> @@ -4058,19 +4060,25 @@ static struct irq_chip its_vpe_irq_chip = { > >> > >> static struct its_node *find_4_1_its(void) > >> { > >> - static struct its_node *its = NULL; > >> + struct its_node *its = NULL; > >> + struct its_node *its_non_cpu_node = NULL; > >> + int cpu = smp_processor_id(); > >> > >> - if (!its) { > >> - list_for_each_entry(its, &its_nodes, entry) { > >> - if (is_v4_1(its)) > >> - return its; > >> - } > >> + if (per_cpu(its_on_cpu, cpu)) > >> + return per_cpu(its_on_cpu, cpu); > >> > >> - /* Oops? */ > >> - its = NULL; > >> - } > >> + list_for_each_entry(its, &its_nodes, entry) { > >> + if (is_v4_1(its) && its->numa_node == cpu_to_node(cpu)) { > >> + per_cpu(its_on_cpu, cpu) = its; > >> + return its; > >> + } else if (is_v4_1(its)) > >> + its_non_cpu_node = its; > >> + } > > Why do you consider the NUMA node instead of the ITS' own affinity? > > SVPET gives you some notion of distance with the RDs, and that'd > > probably be useful. > > I assumed BIOS should report NUMA node following real topology, use NUMA node > for simplicity. NUMA is about CPU memory access, and doesn't quite describe how the ITS fits there. I know people have abused this when the GIC didn't have this notion, but we're over that now. The ITS has the most precise information (ITS->RD->CPU), and we also need to make this work for systems that do not use ACPI. This is pretty easy to do as we inherit the VPE table from the ITS on secondary CPUs, and that's the right spot to populate your table. I'd expect something like this to do the trick: diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 40ebf1726393..bfcbc5a46c1c 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -119,6 +119,8 @@ struct its_node { int vlpi_redist_offset; }; +static DEFINE_PER_CPU(struct its_node *, local_4_1_its); + #define is_v4(its) (!!((its)->typer & GITS_TYPER_VLPIS)) #define is_v4_1(its) (!!((its)->typer & GITS_TYPER_VMAPP)) #define device_ids(its) (FIELD_GET(GITS_TYPER_DEVBITS, (its)->typer) + 1) @@ -2729,6 +2731,8 @@ static u64 inherit_vpe_l1_table_from_its(void) } val |= FIELD_PREP(GICR_VPROPBASER_4_1_SIZE, GITS_BASER_NR_PAGES(baser) - 1); + *this_cpu_ptr(&local_4_1_its) = its; + return val; } @@ -2766,6 +2770,8 @@ static u64 inherit_vpe_l1_table_from_rd(cpumask_t **mask) gic_data_rdist()->vpe_l1_base = gic_data_rdist_cpu(cpu)->vpe_l1_base; *mask = gic_data_rdist_cpu(cpu)->vpe_table_mask; + *this_cpu_ptr(&local_4_1_its) = *per_cpu_ptr(&local_4_1_its, cpu); + return val; } @@ -4078,8 +4084,9 @@ static struct irq_chip its_vpe_irq_chip = { static struct its_node *find_4_1_its(void) { - static struct its_node *its = NULL; + struct its_node *its; + its = *this_cpu_ptr(&local_4_1_its); if (!its) { list_for_each_entry(its, &its_nodes, entry) { if (is_v4_1(its)) *if* there is no matching affinity between ITS and RDs, you can then fallback to NUMA nodes. But using the architected mechanism should be the first port of call. > > > > >> > >> - return its; > >> + if (!per_cpu(its_on_cpu, cpu) && its_non_cpu_node) > >> + per_cpu(its_on_cpu, cpu) = its_non_cpu_node; > >> + > >> + return its_non_cpu_node; > >> } > > Urgh. Mixing init and runtime is awful. Why isn't this initialised > > when a CPU comes up? We already have all the infrastructure. > > The original find_4_1_its use "static struct its_node *its" to save 4_1 ITS, and > it's init inside this function. So, to follow this, I tried to not modify this usage. Sure, but this is already bad, and you're making it worse. Please take this as an opportunity to make things better. > > > > But the biggest question is "what sort of performance improvement does > > this bring"? You give no numbers, no way to evaluate anything. > > > > I've asked for that times and times again: if your changes are > > claiming a performance improvement, please back it up. It's not that > > hard. > > On a 2-socket environment, reported as 2-NUMA, each socket with one ITS > and 32 cpu, GICv4.1 enabled. > For performance, I deploy a 4U8G guest, 4 vcpu on same socket. > When I deploy guest on socket0, kvm-unit-tests ipi_hw result is 850ns. It > test the delay from one vcpu sending ipi to another vcpu receiving ipi in guest. > When I deploy guest on socket1, the result is 750ns. > The reason is VSGI sender always use lasted reported ITS to inject VSGI. > The access from cpu to other-socket ITS will cost 100ns more compared to cpu > to local ITS. Right, this is exactly the sort of information I want to capture in a commit message. Because a 12% reduction in IPI latency is *huge*, and justifies the change. Please add it when you respin the patch. Thanks, M. -- Without deviation from the norm, progress is not possible.