[RESEND PATCH] irqchip/gic-v4.1: Use the ITS of the NUMA node where current cpu is located

[Marc Zyngier]

On Tue, 25 Jun 2024 02:40:19 +0100,
Nianyao Tang <tangnianyao at huawei.com> 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?

> 
> 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?

> (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.

> 
> Signed-off-by: Nianyao Tang <tangnianyao at huawei.com>
> ---
>  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".

> +
>  #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.

>  
> -	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.

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.

Thanks,

	M.

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