From: "Moger, Babu" <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
corbet@lwn.net, fenghua.yu@intel.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com
Cc: x86@kernel.org, hpa@zytor.com, paulmck@kernel.org,
rdunlap@infradead.org, tj@kernel.org, peterz@infradead.org,
yanjiewtw@gmail.com, kim.phillips@amd.com,
lukas.bulwahn@gmail.com, seanjc@google.com, jmattson@google.com,
leitao@debian.org, jpoimboe@kernel.org,
rick.p.edgecombe@intel.com, kirill.shutemov@linux.intel.com,
jithu.joseph@intel.com, kai.huang@intel.com,
kan.liang@linux.intel.com, daniel.sneddon@linux.intel.com,
pbonzini@redhat.com, sandipan.das@amd.com,
ilpo.jarvinen@linux.intel.com, peternewman@google.com,
maciej.wieczor-retman@intel.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, eranian@google.com,
james.morse@arm.com
Subject: Re: [PATCH v5 00/20] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC)
Date: Wed, 17 Jul 2024 12:19:17 -0500 [thread overview]
Message-ID: <1c50b589-a738-4ae6-8362-bd1ce0d0dc98@amd.com> (raw)
In-Reply-To: <e04b721a-b5cb-4089-a3ad-125a6247e5b8@intel.com>
Hi Reinette,
On 7/12/24 17:03, Reinette Chatre wrote:
> Hi Babu,
>
> On 7/3/24 2:48 PM, Babu Moger wrote:
>> # Linux Implementation
>>
>> Linux resctrl subsystem provides the interface to count maximum of two
>> memory bandwidth events per group, from a combination of available total
>> and local events. Keeping the current interface, users can enable a maximum
>> of 2 ABMC counters per group. User will also have the option to enable only
>> one counter to the group. If the system runs out of assignable ABMC
>> counters, kernel will display an error. Users need to disable an already
>> enabled counter to make space for new assignments.
>
> The implementation appears to be converging on an interface that can
> be generic enough to be used by other features discussed along the way.
> "Linux implementation" summary can thus add:
>
> Create a generic interface aimed to support user space assignment
> of scarce counters used for monitoring. First usage of interface
> is by ABMC with option to expand usage to "soft-RMID" and MPAM
> counters in future.
Sure.
>
>
>> # Examples
>>
>> a. Check if ABMC support is available
>> #mount -t resctrl resctrl /sys/fs/resctrl/
>>
>> #cat /sys/fs/resctrl/info/L3_MON/mbm_mode
>> [abmc]
>> legacy
>>
>> Linux kernel detected ABMC feature and it is enabled.
>
> How about renaming "abmc" to "mbm_cntrs"? This will match the num_mbm_cntrs
> info file and be the final step to make this generic so that another
> architecture
> can more easily support assignining hardware counters without needing to call
> the feature AMD's "abmc".
I think we aleady settled this with "mbm_cntr_assignable".
For soft-RMID" it will be mbm_sw_assignable.
>
> Expanding on this it may be possible to add a new "sw_mbm_cntrs" feature that
> will be the "soft-RMID" feature while also reflecting the "mbm_cntrs" name
> so that when user space enables that feature its properties can be found in
> "num_mbm_cntrs".
>
> The "abmc" kernel parameter remains but that does seem separate from this
> resctrl fs feature since it is explicitly tied to X86_FEATURE_ABMC surely
> making it architecture specific.
>
>>
>> b. Check how many ABMC counters are available.
>>
>> #cat /sys/fs/resctrl/info/L3_MON/num_cntrs
>> 32
>
> This is now num_mbm_cntrs
Sure.
>
>>
>> c. Create few resctrl groups.
>>
>> # mkdir /sys/fs/resctrl/mon_groups/child_default_mon_grp
>> # mkdir /sys/fs/resctrl/non_default_ctrl_mon_grp
>> # mkdir
>> /sys/fs/resctrl/non_default_ctrl_mon_grp/mon_groups/child_non_default_mon_grp
>>
>>
>> d. This series adds a new interface file
>> /sys/fs/resctrl/info/L3_MON/mbm_control
>> to list and modify the group's monitoring states. File provides
>> single place
>> to list monitoring states of all the resctrl groups. It makes it
>> easier for
>> user space to learn about the counters are used without needing to
>> traverse
>> all the groups thus reducing the number of filesystem calls.
>>
>> The list follows the following format:
>>
>> "<CTRL_MON group>/<MON group>/<domain_id>=<flags>"
>>
>> Format for specific type of groups:
>>
>> * Default CTRL_MON group:
>> "//<domain_id>=<flags>"
>>
>> * Non-default CTRL_MON group:
>> "<CTRL_MON group>//<domain_id>=<flags>"
>>
>> * Child MON group of default CTRL_MON group:
>> "/<MON group>/<domain_id>=<flags>"
>>
>> * Child MON group of non-default CTRL_MON group:
>> "<CTRL_MON group>/<MON group>/<domain_id>=<flags>"
>>
>> Flags can be one of the following:
>>
>> t MBM total event is enabled.
>> l MBM local event is enabled.
>> tl Both total and local MBM events are enabled.
>> _ None of the MBM events are enabled
>
> The language needs to be changed here (and in the many copied places) to
> be specific about what setting the flag accomplishes. For example, in
> "legacy" mode user space can be expected to find all events enabled, no?
> Needing a new feature to set a flag to accomplish something that is
> possible in legacy mode can thus cause confusion.
Yes. It is possible to do it. But I feel unnessassary.
>
> If I understand the implementation reading "mbm_control" will fail
> if system is ABMC capable but it is disabled. Why can "mbm_control" not
> always be displayed to user space? For example, what if "mbm_control" is
> always available to user space and it can provide specific information to
> user space. For example:
> t MBM total event is enabled but may not always be counted.
> T MBM total event is enabled and being counted.
>
> On AMD systems resource groups will have "t" associated with monitor
> groups when ABMC disabled, "T" when ABMC enabled and a counter assigned.
> On Intel systems monitor groups will always have "T".
I think more flags will add more confusion.
>
> For "soft-RMID" the flag could possible continue to be "T"?
>
> I am trying to find ways to communicate to user space consistently
> and clearly and any insights will be appreciated. We really do not want
> to add this interface and then find that it just causes confusion.
>
> It is not quite obvious to me when the new files should be visible and
> what they should present to the user. "mbm_mode" is now always visible.
> Should "num_mbm_cntrs" not also always be visible? Right now "num_mbm_cntrs"
> appears to be only associated to ABMC, should it not also, for example,
> be the file that "soft-RMID" may use to share how many counters are
> available? Its contents will thus be dynamic based on which "MBM mode" is
> active, begging the question, what should it contain when "legacy" mode is
> enabled, should "num_mbm_cntrs" perhaps show "0" to user space when
> "legacy" mode is active?
Its good we have this discussion.
How about we go with simple way for now. The mbm_mode will only available
when ABMC or Soft_RMID(MPAM feature) is supported. Same way for the
num_mbm_cntrs.
>
>>
>> Examples:
>>
>> # cat /sys/fs/resctrl/info/L3_MON/mbm_control
>> non_default_ctrl_mon_grp//0=tl;1=tl;
>> non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=tl;
>> //0=tl;1=tl;
>> /child_default_mon_grp/0=tl;1=tl;
>>
>> There are four groups and all the groups have local and total
>> event enabled on domain 0 and 1.
>
> "local and total event" is vague, can it be made specific with, for example,
> "local and total MBM events"
Sure.
>
>>
>> =tl means both total and local events are enabled.
>
> Same here (and all copied places in this series)
Sure.
>
>>
>> "//" - This is a default CTRL_MON group
>>
>> "non_default_ctrl_mon_grp//" - This is non-default CTRL_MON group
>>
>> "/child_default_mon_grp/" - This is Child MON group of the defult
>> group
>
> Same typos as in previous version of cover letter.
Oh. no. Will fix it.
>
>>
>> "non_default_ctrl_mon_grp/child_non_default_mon_grp/" - This is child
>> MON group of the non-default group
>>
>> e. Update the group assignment states using the interface file
>> /sys/fs/resctrl/info/L3_MON/mbm_control.
>>
>> The write format is similar to the above list format with addition of
>> op-code for the assignment operation.
>>
>> * Default CTRL_MON group:
>> "//<domain_id><op-code><flags>"
>>
>> * Non-default CTRL_MON group:
>> "<CTRL_MON group>//<domain_id><op-code><flags>"
>>
>> * Child MON group of default CTRL_MON group:
>> "/<MON group>/<domain_id><op-code><flags>"
>>
>> * Child MON group of non-default CTRL_MON group:
>> "<CTRL_MON group>/<MON group>/<domain_id><op-code><flags>"
>>
>> Op-code can be one of the following:
>>
>> = Update the assignment to match the flag.
>> + Assign a new state.
>> - Unassign a new state.
>
> Please be consistent with terminology. Above switches between "flag"
> and "state" while it then continues below using "event". Also,
> "Unassign a _new_ state" is unexpected, it should probably be an
> _existing_ (not "new") state/flag/event?
I will use event consistantly.
>
>>
>> Flags can be one of the following:
>>
>> t MBM total event.
>> l MBM local event.
>> tl Both total and local MBM events.
>> _ None of the MBM events. Only works with '=' op-code.
>>
>> Initial group status:
>> # cat /sys/fs/resctrl/info/L3_MON/mbm_control
>> non_default_ctrl_mon_grp//0=tl;1=tl;
>> non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=tl;
>> //0=tl;1=tl;
>> /child_default_mon_grp/0=tl;1=tl;
>>
>> To update the default group to enable only total event on domain 0:
>> # echo "//0=t" > /sys/fs/resctrl/info/L3_MON/mbm_control
>>
>> Assignment status after the update:
>> # cat /sys/fs/resctrl/info/L3_MON/mbm_control
>> non_default_ctrl_mon_grp//0=tl;1=tl;
>> non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=tl;
>> //0=t;1=tl;
>> /child_default_mon_grp/0=tl;1=tl;
>>
>> To update the MON group child_default_mon_grp to remove total event
>> on domain 1:
>> # echo "/child_default_mon_grp/1-t" >
>> /sys/fs/resctrl/info/L3_MON/mbm_control
>>
>> Assignment status after the update:
>> $ cat /sys/fs/resctrl/info/L3_MON/mbm_control
>> non_default_ctrl_mon_grp//0=tl;1=tl;
>> non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=tl;
>> //0=t;1=tl;
>> /child_default_mon_grp/0=tl;1=l;
>>
>> To update the MON group
>> non_default_ctrl_mon_grp/child_non_default_mon_grp to
>> remove both local and total events on domain 1:
>> # echo "non_default_ctrl_mon_grp/child_non_default_mon_grp/1=_" >
>> /sys/fs/resctrl/info/L3_MON/mbm_control
>>
>> Assignment status after the update:
>> non_default_ctrl_mon_grp//0=tl;1=tl;
>> non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=_;
>> //0=t;1=tl;
>> /child_default_mon_grp/0=tl;1=l;
>>
>> To update the default group to add a local event domain 0.
>> # echo "//0+l" > /sys/fs/resctrl/info/L3_MON/mbm_control
>>
>> Assignment status after the update:
>> # cat /sys/fs/resctrl/info/L3_MON/mbm_control
>> non_default_ctrl_mon_grp//0=tl;1=tl;
>> non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=_;
>> //0=tl;1=tl;
>> /child_default_mon_grp/0=tl;1=l;
>>
>>
>> f. Read the event mbm_total_bytes and mbm_local_bytes of the default group.
>> There is no change in reading the events with ABMC. If the event is
>> unassigned
>> when reading, then the read will come back as "Unassigned".
>>
>> # cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_total_bytes
>> 779247936
>> # cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_local_bytes
>> 765207488
>>
>> g. Users will have the option to go back to legacy mbm_mode if required.
>> This can be done using the following command. Note that switching the
>> mbm_mode will reset all the mbm counters of all resctrl groups.
>
> mbm -> MBM (throughout)
Sure.
>
>>
>> # echo "legacy" > /sys/fs/resctrl/info/L3_MON/mbm_mode
>> # cat /sys/fs/resctrl/info/L3_MON/mbm_mode
>> abmc
>> [legacy]
>>
>> h. Check the bandwidth configuration for the group. Note that bandwidth
>> configuration has a domain scope. Total event defaults to 0x7F (to
>> count all the events) and local event defaults to 0x15 (to count all
>> the local numa events). The event bitmap decoding is available at
>> https://www.kernel.org/doc/Documentation/x86/resctrl.rst
>> in section "mbm_total_bytes_config", "mbm_local_bytes_config":
>>
>> #cat /sys/fs/resctrl/info/L3_MON/mbm_total_bytes_config
>> 0=0x7f;1=0x7f
>>
>> #cat /sys/fs/resctrl/info/L3_MON/mbm_local_bytes_config
>> 0=0x15;1=0x15
>>
>> j. Change the bandwidth source for domain 0 for the total event to count
>> only reads.
>> Note that this change effects total events on the domain 0.
>>
>> #echo 0=0x33 > /sys/fs/resctrl/info/L3_MON/mbm_total_bytes_config
>> #cat /sys/fs/resctrl/info/L3_MON/mbm_total_bytes_config
>> 0=0x33;1=0x7F
>>
>> k. Now read the total event again. The first read will come back with
>> "Unavailable"
>> status. The subsequent read of mbm_total_bytes will display only the
>> read events.
>>
>> #cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_total_bytes
>> Unavailable
>> #cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_total_bytes
>> 314101
>>
>> l. Unmount the resctrl
>>
>> #umount /sys/fs/resctrl/
>>
>
> Reinette
>
--
Thanks
Babu Moger
next prev parent reply other threads:[~2024-07-17 17:19 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-03 21:48 Babu Moger
2024-07-03 21:48 ` [PATCH v5 01/20] x86/cpufeatures: Add support for " Babu Moger
2024-07-12 21:55 ` Reinette Chatre
2024-07-15 18:36 ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 02/20] x86/resctrl: Add ABMC feature in the command line options Babu Moger
2024-07-03 21:48 ` [PATCH v5 03/20] x86/resctrl: Consolidate monitoring related data from rdt_resource Babu Moger
2024-07-12 21:57 ` Reinette Chatre
2024-07-15 19:05 ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 04/20] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details Babu Moger
2024-07-12 22:04 ` Reinette Chatre
2024-07-15 20:04 ` Moger, Babu
2024-07-16 15:11 ` Reinette Chatre
2024-07-03 21:48 ` [PATCH v5 05/20] x86/resctrl: Introduce resctrl_file_fflags_init() to initialize fflags Babu Moger
2024-07-12 22:04 ` Reinette Chatre
2024-07-03 21:48 ` [PATCH v5 06/20] x86/resctrl: Add support to enable/disable AMD ABMC feature Babu Moger
2024-07-12 22:05 ` Reinette Chatre
2024-07-16 15:13 ` Moger, Babu
2024-07-16 17:51 ` Reinette Chatre
2024-07-16 18:48 ` Moger, Babu
2024-07-16 20:41 ` Reinette Chatre
2024-07-18 21:11 ` Moger, Babu
2024-08-16 16:29 ` James Morse
2024-07-03 21:48 ` [PATCH v5 07/20] x86/resctrl: Introduce the interface to display monitor mode Babu Moger
2024-07-12 22:06 ` Reinette Chatre
2024-07-16 16:51 ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 08/20] x86/resctrl: Introduce interface to display number of monitoring counters Babu Moger
2024-07-03 21:48 ` [PATCH v5 09/20] x86/resctrl: Initialize monitor counters bitmap Babu Moger
2024-07-12 22:07 ` Reinette Chatre
2024-07-16 17:59 ` Moger, Babu
2024-07-26 22:48 ` Peter Newman
2024-07-26 23:53 ` Moger, Babu
2024-08-01 21:05 ` Reinette Chatre
2024-07-03 21:48 ` [PATCH v5 10/20] x86/resctrl: Introduce mbm_total_cfg and mbm_local_cfg Babu Moger
2024-07-12 22:08 ` Reinette Chatre
2024-07-16 19:21 ` Moger, Babu
2024-07-16 20:42 ` Reinette Chatre
2024-07-16 22:43 ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 11/20] x86/resctrl: Remove MSR reading of event configuration value Babu Moger
2024-07-12 22:10 ` Reinette Chatre
2024-07-16 19:34 ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 12/20] x86/resctrl: Add data structures and definitions for ABMC assignment Babu Moger
2024-07-12 22:13 ` Reinette Chatre
2024-07-16 20:24 ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 13/20] x86/resctrl: Add the interface to assign hardware counter Babu Moger
2024-07-12 22:09 ` Reinette Chatre
2024-07-16 20:45 ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 14/20] x86/resctrl: Add the interface to unassign " Babu Moger
2024-07-03 21:48 ` [PATCH v5 15/20] x86/resctrl: Assign/unassign counters by default when ABMC is enabled Babu Moger
2024-07-12 22:10 ` Reinette Chatre
2024-07-16 20:58 ` Moger, Babu
2024-07-26 23:22 ` Peter Newman
2024-07-26 23:57 ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 16/20] x86/resctrl: Report "Unassigned" for MBM events in ABMC mode Babu Moger
2024-07-12 22:13 ` Reinette Chatre
2024-07-16 21:04 ` Moger, Babu
2024-07-13 20:26 ` Markus Elfring
2024-07-03 21:48 ` [PATCH v5 17/20] x86/resctrl: Introduce the interface switch between monitor modes Babu Moger
2024-07-12 22:14 ` Reinette Chatre
2024-07-16 22:46 ` Moger, Babu
2024-07-13 7:15 ` Markus Elfring
2024-07-03 21:48 ` [PATCH v5 18/20] x86/resctrl: Enable AMD ABMC feature by default when supported Babu Moger
2024-07-12 22:15 ` Reinette Chatre
2024-07-16 23:23 ` Moger, Babu
2024-07-26 0:16 ` Moger, Babu
2024-08-01 21:40 ` Reinette Chatre
2024-07-03 21:48 ` [PATCH v5 19/20] x86/resctrl: Introduce interface to list monitor states of all the groups Babu Moger
2024-07-12 22:16 ` Reinette Chatre
2024-07-17 15:22 ` Moger, Babu
2024-08-01 21:37 ` Reinette Chatre
2024-08-02 16:10 ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 20/20] x86/resctrl: Introduce interface to modify assignment states of " Babu Moger
2024-07-12 22:17 ` Reinette Chatre
2024-07-17 16:22 ` Moger, Babu
2024-07-25 0:03 ` Peter Newman
2024-07-25 1:22 ` Moger, Babu
2024-07-25 17:11 ` Peter Newman
2024-07-25 17:28 ` Moger, Babu
2024-08-01 18:56 ` Reinette Chatre
2024-08-01 19:40 ` Moger, Babu
2024-07-12 22:03 ` [PATCH v5 00/20] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Reinette Chatre
2024-07-17 17:19 ` Moger, Babu [this message]
2024-08-01 21:49 ` Reinette Chatre
2024-08-01 22:45 ` Peter Newman
2024-08-02 16:13 ` Reinette Chatre
2024-08-02 18:49 ` Moger, Babu
2024-08-02 19:13 ` Peter Newman
2024-08-02 20:23 ` Moger, Babu
2024-08-02 18:49 ` Peter Newman
2024-08-02 20:38 ` Moger, Babu
2024-08-02 20:55 ` Reinette Chatre
2024-08-02 22:50 ` Peter Newman
2024-08-14 17:37 ` Reinette Chatre
2024-08-15 23:06 ` Peter Newman
2024-08-16 1:45 ` Reinette Chatre
2024-08-03 0:49 ` Moger, Babu
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=1c50b589-a738-4ae6-8362-bd1ce0d0dc98@amd.com \
--to=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=james.morse@arm.com \
--cc=jithu.joseph@intel.com \
--cc=jmattson@google.com \
--cc=jpoimboe@kernel.org \
--cc=kai.huang@intel.com \
--cc=kan.liang@linux.intel.com \
--cc=kim.phillips@amd.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=leitao@debian.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=maciej.wieczor-retman@intel.com \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peternewman@google.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=sandipan.das@amd.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=x86@kernel.org \
--cc=yanjiewtw@gmail.com \
/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®