From: Reinette Chatre <reinette.chatre@intel.com>
To: Peter Newman <peternewman@google.com>, Fenghua Yu <fenghua.yu@intel.com>
Cc: Babu Moger <babu.moger@amd.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Stephane Eranian <eranian@google.com>,
James Morse <james.morse@arm.com>, <linux-kernel@vger.kernel.org>,
<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH v1 2/9] x86/resctrl: Hold a spinlock in __rmid_read() on AMD
Date: Thu, 11 May 2023 14:35:53 -0700 [thread overview]
Message-ID: <242db225-8ddc-968e-a754-6aaefd1b7da9@intel.com> (raw)
In-Reply-To: <20230421141723.2405942-3-peternewman@google.com>
Hi Peter,
On 4/21/2023 7:17 AM, Peter Newman wrote:
> From: Stephane Eranian <eranian@google.com>
>
> In AMD PQoS Versions 1.0 and 2.0, IA32_QM_EVTSEL MSR is shared by all
> processors in a QOS domain. So there's a chance it can read a different
> event when two processors are reading the counter concurrently. Add a
> spinlock to prevent this race.
This is unclear to me. As I understand it this changelog is written as
though there is a race that is being fixed. I believe that rdtgroup_mutex
currently protects against such races. I thus at first thought that
this is a prep patch for the introduction of the new soft RMID feature,
but instead this new spinlock is used independent of the soft RMID feature.
I think the spinlock is unnecessary when the soft RMID feature is disabled.
> Co-developed-by: Peter Newman <peternewman@google.com>
> Signed-off-by: Peter Newman <peternewman@google.com>
> Signed-off-by: Stephane Eranian <eranian@google.com>
> ---
> arch/x86/kernel/cpu/resctrl/core.c | 41 ++++++++++++++++++++++++++
> arch/x86/kernel/cpu/resctrl/internal.h | 5 ++++
> arch/x86/kernel/cpu/resctrl/monitor.c | 14 +++++++--
> 3 files changed, 57 insertions(+), 3 deletions(-)
>
...
> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
> index 85ceaf9a31ac..02a062558c67 100644
> --- a/arch/x86/kernel/cpu/resctrl/internal.h
> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
> @@ -325,6 +325,7 @@ struct arch_mbm_state {
> * @ctrl_val: array of cache or mem ctrl values (indexed by CLOSID)
> * @arch_mbm_total: arch private state for MBM total bandwidth
> * @arch_mbm_local: arch private state for MBM local bandwidth
> + * @lock: serializes counter reads when QM_EVTSEL MSR is shared per-domain
> *
> * Members of this structure are accessed via helpers that provide abstraction.
> */
> @@ -333,6 +334,7 @@ struct rdt_hw_domain {
> u32 *ctrl_val;
> struct arch_mbm_state *arch_mbm_total;
> struct arch_mbm_state *arch_mbm_local;
> + raw_spinlock_t evtsel_lock;
> };
Please note the difference between the member name in the struct ("evtsel_lock")
and its description ("lock").
>
> static inline struct rdt_hw_domain *resctrl_to_arch_dom(struct rdt_domain *r)
> @@ -428,6 +430,9 @@ extern struct rdt_hw_resource rdt_resources_all[];
> extern struct rdtgroup rdtgroup_default;
> DECLARE_STATIC_KEY_FALSE(rdt_alloc_enable_key);
>
> +/* Serialization required in resctrl_arch_rmid_read(). */
> +DECLARE_STATIC_KEY_FALSE(rmid_read_locked);
> +
> extern struct dentry *debugfs_resctrl;
>
> enum resctrl_res_level {
> diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
> index 20952419be75..2de8397f91cd 100644
> --- a/arch/x86/kernel/cpu/resctrl/monitor.c
> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c
> @@ -146,10 +146,15 @@ static inline struct rmid_entry *__rmid_entry(u32 rmid)
> return entry;
> }
>
> -static int __rmid_read(u32 rmid, enum resctrl_event_id eventid, u64 *val)
> +static int __rmid_read(struct rdt_hw_domain *hw_dom, u32 rmid,
> + enum resctrl_event_id eventid, u64 *val)
> {
> + unsigned long flags;
> u64 msr_val;
>
> + if (static_branch_likely(&rmid_read_locked))
Why static_branch_likely() as opposed to static_branch_unlikely()?
> + raw_spin_lock_irqsave(&hw_dom->evtsel_lock, flags);
> +
> /*
> * As per the SDM, when IA32_QM_EVTSEL.EvtID (bits 7:0) is configured
> * with a valid event code for supported resource type and the bits
> @@ -161,6 +166,9 @@ static int __rmid_read(u32 rmid, enum resctrl_event_id eventid, u64 *val)
> wrmsr(MSR_IA32_QM_EVTSEL, eventid, rmid);
> rdmsrl(MSR_IA32_QM_CTR, msr_val);
>
> + if (static_branch_likely(&rmid_read_locked))
> + raw_spin_unlock_irqrestore(&hw_dom->evtsel_lock, flags);
> +
If the first "if (static_branch_likely(&rmid_read_locked))" was taken then the second
if branch _has_ to be taken. It should not be optional to release a lock if it was taken. I
think it would be more robust if a single test of the static key decides whether the
spinlock should be used.
> if (msr_val & RMID_VAL_ERROR)
> return -EIO;
> if (msr_val & RMID_VAL_UNAVAIL)
> @@ -200,7 +208,7 @@ void resctrl_arch_reset_rmid(struct rdt_resource *r, struct rdt_domain *d,
> memset(am, 0, sizeof(*am));
>
> /* Record any initial, non-zero count value. */
> - __rmid_read(rmid, eventid, &am->prev_msr);
> + __rmid_read(hw_dom, rmid, eventid, &am->prev_msr);
> }
> }
>
> @@ -241,7 +249,7 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d,
> if (!cpumask_test_cpu(smp_processor_id(), &d->cpu_mask))
> return -EINVAL;
>
> - ret = __rmid_read(rmid, eventid, &msr_val);
> + ret = __rmid_read(hw_dom, rmid, eventid, &msr_val);
> if (ret)
> return ret;
>
Reinette
next prev parent reply other threads:[~2023-05-11 21:36 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-21 14:17 [PATCH v1 0/9] x86/resctrl: Use soft RMIDs for reliable MBM on AMD Peter Newman
2023-04-21 14:17 ` [PATCH v1 1/9] selftests/resctrl: Verify all RMIDs count together Peter Newman
2023-04-21 14:17 ` [PATCH v1 2/9] x86/resctrl: Hold a spinlock in __rmid_read() on AMD Peter Newman
2023-05-11 21:35 ` Reinette Chatre [this message]
2023-05-12 13:23 ` Peter Newman
2023-05-12 15:23 ` Reinette Chatre
2023-04-21 14:17 ` [PATCH v1 3/9] x86/resctrl: Add resctrl_mbm_flush_cpu() to collect CPUs' MBM events Peter Newman
2023-05-11 21:37 ` Reinette Chatre
2023-05-12 13:25 ` Peter Newman
2023-05-12 15:26 ` Reinette Chatre
2023-05-15 14:42 ` Peter Newman
2023-05-17 0:05 ` Reinette Chatre
2023-12-01 20:56 ` Peter Newman
2023-12-05 21:57 ` Reinette Chatre
2023-12-06 0:33 ` Peter Newman
2023-12-06 1:46 ` Reinette Chatre
2023-12-06 18:38 ` Peter Newman
2023-12-06 20:02 ` Reinette Chatre
2023-05-16 14:18 ` Peter Newman
2023-05-16 14:27 ` Peter Newman
2023-06-01 14:45 ` Peter Newman
2023-06-01 17:14 ` Reinette Chatre
2023-04-21 14:17 ` [PATCH v1 4/9] x86/resctrl: Flush MBM event counts on soft RMID change Peter Newman
2023-05-11 21:37 ` Reinette Chatre
2023-04-21 14:17 ` [PATCH v1 5/9] x86/resctrl: Call mon_event_count() directly for soft RMIDs Peter Newman
2023-05-11 21:38 ` Reinette Chatre
2023-04-21 14:17 ` [PATCH v1 6/9] x86/resctrl: Create soft RMID version of __mon_event_count() Peter Newman
2023-05-11 21:38 ` Reinette Chatre
2023-04-21 14:17 ` [PATCH v1 7/9] x86/resctrl: Assign HW RMIDs to CPUs for soft RMID Peter Newman
2023-05-11 21:39 ` Reinette Chatre
2023-05-16 14:49 ` Peter Newman
2023-05-17 0:06 ` Reinette Chatre
2023-06-06 13:31 ` Peter Newman
2023-06-06 13:36 ` Peter Newman
2023-04-21 14:17 ` [PATCH v1 8/9] x86/resctrl: Use mbm_update() to push soft RMID counts Peter Newman
2023-05-11 21:40 ` Reinette Chatre
2023-06-02 12:42 ` Peter Newman
2023-06-06 13:48 ` Peter Newman
2023-04-21 14:17 ` [PATCH v1 9/9] x86/resctrl: Add mount option to enable soft RMID Peter Newman
2023-05-11 21:41 ` Reinette Chatre
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=242db225-8ddc-968e-a754-6aaefd1b7da9@intel.com \
--to=reinette.chatre@intel.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peternewman@google.com \
--cc=tglx@linutronix.de \
--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