From: Reinette Chatre <reinette.chatre@intel.com>
To: Peter Newman <peternewman@google.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
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 7/9] x86/resctrl: Assign HW RMIDs to CPUs for soft RMID
Date: Tue, 16 May 2023 17:06:31 -0700 [thread overview]
Message-ID: <00b0c70d-eed8-8dc1-8046-25764d991bf4@intel.com> (raw)
In-Reply-To: <CALPaoCj76eMTF+VPT8_52_D+fKpWt2ENcyavJ4aooCOo9TYKFw@mail.gmail.com>
Hi Peter,
On 5/16/2023 7:49 AM, Peter Newman wrote:
> On Thu, May 11, 2023 at 11:40 PM Reinette Chatre
> <reinette.chatre@intel.com> wrote:
>> On 4/21/2023 7:17 AM, Peter Newman wrote:
>>> + rmid = 0;
>>> + for_each_cpu(i, &l3ci->shared_cpu_map) {
>>> + if (i == cpu)
>>> + break;
>>> + rmid++;
>>> + }
>>> +
>>> + return rmid;
>>> +}
>>
>> I do not see any impact to the (soft) RMIDs that can be assigned to monitor
>> groups, yet from what I understand a generic "RMID" is used as index to MBM state.
>> Is this correct? A hardware RMID and software RMID would thus share the
>> same MBM state. If this is correct I think we need to work on making
>> the boundaries between hard and soft RMID more clear.
>
> The only RMID-indexed state used by soft RMIDs right now is
> mbm_state::soft_rmid_bytes. The other aspect of the boundary is
> ensuring that nothing will access the hard RMID-specific state for a
> soft RMID.
>
> The remainder of the mbm_state is only accessed by the software
> controller, which you suggested that I disable.
>
> The arch_mbm_state is accessed only through resctrl_arch_rmid_read()
> and resctrl_arch_reset_rmid(), which are called by __mon_event_count()
> or the limbo handler.
>
> __mon_event_count() is aware of soft RMIDs, so I would just need to
> ensure the software controller is disabled and never put any RMIDs on
> the limbo list. To be safe, I can also add
> WARN_ON_ONCE(rdt_mon_soft_rmid) to the rmid-indexing of the mbm_state
> arrays in the software controller and before the
> resctrl_arch_rmid_read() call in the limbo handler to catch if they're
> ever using soft RMIDs.
I understand and trust that you can ensure that this implementation is
done safely. Please also consider how future changes to resctrl may stumble
if there are not clear boundaries. You may be able to "ensure the software
controller is disabled and never put any RMIDs on the limbo list", but
consider if these rules will be clear to somebody who comes along in a year
or more.
Documenting the data structures with these unique usages will help.
Specific accessors can sometimes be useful to make it obvious in which state
the data is being accessed and what data can be accessed. Using WARN
as you suggest is a useful tool.
Reinette
next prev parent reply other threads:[~2023-05-17 0:06 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
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 [this message]
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=00b0c70d-eed8-8dc1-8046-25764d991bf4@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