mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Reinette Chatre <reinette.chatre@intel.com>,
	Peter Newman <peternewman@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	x86@kernel.org
Cc: Shaopeng Tan <tan.shaopeng@fujitsu.com>,
	Jamie Iles <quic_jiles@quicinc.com>,
	Babu Moger <babu.moger@amd.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Drew Fustini <dfustini@baylibre.com>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	patches@lists.linux.dev
Subject: Re: [PATCH v4 1/2] x86/resctrl: Pass domain to target CPU
Date: Fri, 8 Mar 2024 18:26:56 +0000	[thread overview]
Message-ID: <26f23ba4-4ca5-41f6-b920-08515f494ae5@arm.com> (raw)
In-Reply-To: <20240228193717.8170-1-tony.luck@intel.com>

Hi Tony,

On 28/02/2024 19:36, Tony Luck wrote:
> reset_all_ctrls() and resctrl_arch_update_domains() use on_each_cpu_mask()
> to call rdt_ctrl_update() on potentially one CPU from each domain.
> 
> But this means rdt_ctrl_update() needs to figure out which domain to
> apply changes to. Doing so requires a search of all domains in a resource,
> which can only be done safely if cpus_lock is held. Both callers do hold
> this lock, but there isn't a way for a function called on another CPU
> via IPI to verify this.
> 
> Commit c0d848fcb09d ("x86/resctrl: Remove lockdep annotation that triggers
> false positive") removed the incorrect assertions.
> 
> Add the target domain to the msr_param structure and
> call rdt_ctrl_update() for each domain separately using
> smp_call_function_single(). This means that rdt_ctrl_update() doesn't
> need to search for the domain and get_domain_from_cpu() can safely assert
> that the cpus_lock is held since the remaining callers do not use IPI.

> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
> index 83e40341583e..acf52aa185e0 100644
> --- a/arch/x86/kernel/cpu/resctrl/core.c
> +++ b/arch/x86/kernel/cpu/resctrl/core.c
> @@ -362,6 +362,8 @@ struct rdt_domain *get_domain_from_cpu(int cpu, struct rdt_resource *r)
>  {
>  	struct rdt_domain *d;
>  
> +	lockdep_assert_cpus_held();


(Huzzah!)


>  	list_for_each_entry(d, &r->domains, list) {
>  		/* Find the domain that contains this CPU */
>  		if (cpumask_test_cpu(cpu, &d->cpu_mask))

> diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
> index 7997b47743a2..a3a0fd80daa8 100644
> --- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
> +++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
> @@ -315,27 +300,27 @@ int resctrl_arch_update_domains(struct rdt_resource *r, u32 closid)

[..]

> -	msr_param.res = NULL;
>  	list_for_each_entry(d, &r->domains, list) {
>  		hw_dom = resctrl_to_arch_dom(d);
> +		msr_param.res = NULL;
> +		msr_param.dom = d;
>  		for (t = 0; t < CDP_NUM_TYPES; t++) {
>  			cfg = &hw_dom->d_resctrl.staged_config[t];
>  			if (!cfg->have_new_ctrl)
>  				continue;
>  
>  			idx = get_config_index(closid, t);
> -			if (!apply_config(hw_dom, cfg, idx, cpu_mask))
> +			if (cfg->new_ctrl == hw_dom->ctrl_val[idx])
>  				continue;
> +			hw_dom->ctrl_val[idx] = cfg->new_ctrl;
> +			cpu = cpumask_any(&d->cpu_mask);

If this CPU is part of the domain, then cpumask_any() could chose a different CPU leading
to an IPI, where this CPU could have done the work itself.
smp_call_function_any() has the logic to try and run on this CPU if possible.

As d->cpu_mask is still valid when you call smp_call_function_single(), could we use
smp_call_function_any() instead?


>  			if (!msr_param.res) {
>  				msr_param.low = idx;
> @@ -346,17 +331,10 @@ int resctrl_arch_update_domains(struct rdt_resource *r, u32 closid)
>  				msr_param.high = max(msr_param.high, idx + 1);
>  			}
>  		}
> +		if (msr_param.res)
> +			smp_call_function_single(cpu, rdt_ctrl_update, &msr_param, 1);
>  	}

> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 011e17efb1a6..da4f13db4161 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -2813,16 +2813,13 @@ static int reset_all_ctrls(struct rdt_resource *r)
> @@ -2834,17 +2831,14 @@ static int reset_all_ctrls(struct rdt_resource *r)
>  	 */
>  	list_for_each_entry(d, &r->domains, list) {
>  		hw_dom = resctrl_to_arch_dom(d);
> -		cpumask_set_cpu(cpumask_any(&d->cpu_mask), cpu_mask);
> +		cpu = cpumask_any(&d->cpu_mask);

Same comment about picking an unlucky CPU here, smp_call_function_any() can improve our
chances.


>  		for (i = 0; i < hw_res->num_closid; i++)
>  			hw_dom->ctrl_val[i] = r->default_ctrl;
> +		msr_param.dom = d;
> +		smp_call_function_single(cpu, rdt_ctrl_update, &msr_param, 1);
>  	}

Still:
Reviewed-by: James Morse <james.morse@arm.com>


Thanks!

James


  parent reply	other threads:[~2024-03-08 18:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-28 19:36 Cover-cover letter for two resctrl patch sets Tony Luck
2024-02-28 19:36 ` [PATCH v4 0/2] x86/resctrl: Pass domain to target CPU Tony Luck
2024-02-28 19:36   ` [PATCH v4 1/2] " Tony Luck
2024-03-04 23:07     ` Reinette Chatre
2024-03-05  0:17       ` Luck, Tony
2024-03-05  1:31         ` Reinette Chatre
2024-03-05 16:37           ` Luck, Tony
2024-03-05 16:48             ` Reinette Chatre
2024-03-08 18:26     ` James Morse [this message]
2024-03-08 18:50       ` Luck, Tony
2024-02-28 19:36   ` [PATCH v4 2/2] x86/resctrl: Simplify call convention for MSR update functions Tony Luck
2024-03-04 23:07     ` Reinette Chatre
2024-02-28 19:36 ` [PATCH v15 0/8] Add support for Sub-NUMA cluster (SNC) systems Tony Luck
2024-02-28 19:36   ` [PATCH v15 1/8] x86/resctrl: Prepare for new domain scope Tony Luck
2024-02-28 19:36   ` [PATCH v15 2/8] x86/resctrl: Prepare to split rdt_domain structure Tony Luck
2024-02-28 19:36   ` [PATCH v15 3/8] x86/resctrl: Prepare for different scope for control/monitor operations Tony Luck
2024-02-28 19:36   ` [PATCH v15 4/8] x86/resctrl: Split the rdt_domain and rdt_hw_domain structures Tony Luck
2024-02-28 19:37   ` [PATCH v15 5/8] x86/resctrl: Add node-scope to the options for feature scope Tony Luck
2024-02-28 19:37   ` [PATCH v15 6/8] x86/resctrl: Introduce snc_nodes_per_l3_cache Tony Luck
2024-02-28 19:37   ` [PATCH v15 7/8] x86/resctrl: Sub NUMA Cluster detection and enable Tony Luck
2024-02-28 19:37   ` [PATCH v15 8/8] x86/resctrl: Update documentation with Sub-NUMA cluster changes Tony Luck
2024-03-04 23:07 ` Cover-cover letter for two resctrl patch sets Reinette Chatre
2024-03-05 22:02   ` Konstantin Ryabitsev
2024-03-05 22:27     ` Luck, Tony
2024-03-06  3:11       ` Konstantin Ryabitsev
2024-03-05  7:28 ` Maciej Wieczor-Retman
2024-03-05 17:51   ` Luck, Tony
2024-03-06  7:22     ` Maciej Wieczor-Retman
2024-03-06  7:28 ` Maciej Wieczor-Retman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26f23ba4-4ca5-41f6-b920-08515f494ae5@arm.com \
    --to=james.morse@arm.com \
    --cc=babu.moger@amd.com \
    --cc=corbet@lwn.net \
    --cc=dfustini@baylibre.com \
    --cc=fenghua.yu@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=peternewman@google.com \
    --cc=quic_jiles@quicinc.com \
    --cc=rdunlap@infradead.org \
    --cc=reinette.chatre@intel.com \
    --cc=skhan@linuxfoundation.org \
    --cc=tan.shaopeng@fujitsu.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®