x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC)
Subsystems (3)
Babu Moger
reviewerv10 cover x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC)
This series adds the support for Assignable Bandwidth Monitoring Counters (ABMC). It is also called QoS RMID Pinning feature
Series is written such that it is easier to support other assignable features supported from different vendors.
The feature details are documented in the APM listed below [1].
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3.3 Assignable Bandwidth Monitoring (ABMC). The documentation is available at
The patches are based on top of commitd803bbbb55f4f (tip/master) Merge branch into tip/master: 'x86/tdx'
# Introduction
Users can create as many monitor groups as RMIDs supported by the hardware. However, bandwidth monitoring feature on AMD system only guarantees that RMIDs currently assigned to a processor will be tracked by hardware. The counters of any other RMIDs which are no longer being tracked will be reset to zero. The MBM event counters return "Unavailable" for the RMIDs that are not tracked by hardware. So, there can be only limited number of groups that can give guaranteed monitoring numbers. With ever changing configurations there is no way to definitely know which of these groups are being tracked for certain point of time. Users do not have the option to monitor a group or set of groups for certain period of time without worrying about counter being reset in between.
The ABMC feature provides an option to the user to assign a hardware counter to an RMID, event pair and monitor the bandwidth as long as it is assigned. The assigned RMID will be tracked by the hardware until the user unassigns it manually. There is no need to worry about counters being reset during this period. Additionally, the user can specify a bitmask identifying the specific bandwidth types from the given source to track with the counter.
Without ABMC enabled, monitoring will work in current 'default' mode without assignment option.
# Linux Implementation
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-ABMC" and MPAM counters in future.
Feature adds following interface files:
/sys/fs/resctrl/info/L3_MON/mbm_assign_mode: Reports the list of assignable monitoring features supported. The enclosed brackets indicate which feature is enabled.
/sys/fs/resctrl/info/L3_MON/num_mbm_cntrs: Reports the number of monitoring counters available for assignment.
/sys/fs/resctrl/info/L3_MON/available_mbm_cntrs: Reports the number of monitoring counters free in each domain.
/sys/fs/resctrl/info/L3_MON/mbm_assign_control: Reports the resctrl group and monitor status of each group. Assignment state can be updated by writing to the interface.
# Examples
a. Check if ABMC support is available
#mount -t resctrl resctrl /sys/fs/resctrl/
# cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode [mbm_cntr_assign]
default
ABMC feature is detected and it is enabled.
b. Check how many ABMC counters are available.
# cat /sys/fs/resctrl/info/L3_MON/num_mbm_cntrs 32
c. Check how many ABMC counters are available in each domain.
# cat /sys/fs/resctrl/info/L3_MON/available_mbm_cntrs 0=30;1=30;
d. 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
e. This series adds a new interface file /sys/fs/resctrl/info/L3_MON/mbm_assign_control
to list and modify any 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 used counters without needing to traverse all the groups thus reducing the number of file system 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
Examples:
# cat /sys/fs/resctrl/info/L3_MON/mbm_assign_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.
f. Update the group assignment states using the interface file /sys/fs/resctrl/info/L3_MON/mbm_assign_control.
The write format is similar to the above list format with addition of opcode for the assignment operation.
“<CTRL_MON group>/<MON group>/<domain_id><opcode><flags>”
* Default CTRL_MON group:
"//<domain_id><opcode><flags>"
* Non-default CTRL_MON group:
"<CTRL_MON group>//<domain_id><opcode><flags>"
* Child MON group of default CTRL_MON group:
"/<MON group>/<domain_id><opcode><flags>"
* Child MON group of non-default CTRL_MON group:
"<CTRL_MON group>/<MON group>/<domain_id><opcode><flags>"
Opcode can be one of the following:
= Update the assignment to match the flags.
+ Assign a new MBM event without impacting existing assignments.
- Unassign a MBM event from currently assigned events.
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 '=' opcode. This flag cannot be combined with other flags.
Initial group status:
# cat /sys/fs/resctrl/info/L3_MON/mbm_assign_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_assign_control
Assignment status after the update:
# cat /sys/fs/resctrl/info/L3_MON/mbm_assign_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_assign_control
Assignment status after the update:
$ cat /sys/fs/resctrl/info/L3_MON/mbm_assign_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_assign_control
Assignment status after the update:
$ cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control 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_assign_control
Assignment status after the update:
# cat /sys/fs/resctrl/info/L3_MON/mbm_assign_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;
To update the non default CTRL_MON group non_default_ctrl_mon_grp to unassign all the MBM events on all the domains.
# echo "non_default_ctrl_mon_grp//*=_" > /sys/fs/resctrl/info/L3_MON/mbm_assign_control
Assignment status after the update:
# cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control non_default_ctrl_mon_grp//0=_;1=_; 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;
g. 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
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
i. 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
j. 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
k. Users will have the option to go back to 'default' mbm_assign_mode if required.
This can be done using the following command. Note that switching the mbm_assign_mode will reset all the MBM counters of all resctrl groups.
# echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode mbm_cntr_assign [default]
l. Unmount the resctrl
#umount /sys/fs/resctrl/
---
v10:
Major change is related to domain specific assignment.
Added struct mbm_cntr_cfg inside mon domains. This will handle
the domain specific assignments as discussed in below.
https://lore.kernel.org/lkml/CALPaoCj+zWq1vkHVbXYP0znJbe6Ke3PXPWjtri5AFgD9cQDCUg@mail.gmail.com/
I did not see the need to add cntr_id in mbm_state structure. Not used in the code. Following patches take care of these changes.
Patch 12, 13, 15, 16, 17, 18.
Added __init attribute to cache_alloc_hsw_probe(). Followed function prototype rules (preferred order is storage class before return type).
Moved the mon_config_info structure definition to resctrl.h
Added call resctrl_arch_reset_rmid() to reset the RMID in the domain inside IPI call resctrl_abmc_config_one_amd.
SMP and non-SMP call support is not required in resctrl_arch_config_cntr with new domain specific assign approach/data structure.
Assigned the counter before exposing the event files.
Moved the call rdtgroup_assign_cntrs() inside mkdir_rdt_prepare_rmid_alloc(). This is called both CNTR_MON and MON group creation.
Call mbm_cntr_reset() when unmounted to clear all the assignments.
Fixed the issue with finding the domain in multiple iterations in rdtgroup_process_flags().
Printed full error message with domain information when assign fails.
Taken care of other text comments in all the patches. Patch specific changes are in each patch.
If I missed something please point me and it is not intentional.
v9:
Patch 14 is a new addition.
Major change in patch 24.
Moved the fix patch to address __init attribute to begining of the series. Fixed all the call sequences. Added additional Fixed tags.
Added Reviewed-by where applicable.
Took care of couple of minor merge conflicts with latest code. Re-ordered the MSR in couple of instances.
Added available_mbm_cntrs (patch 14) to print the number of counter in a domain.
Used MBM_EVENT_ARRAY_INDEX macro to get the event index. Introduced rdtgroup_cntr_id_init() to initialize the cntr_id
Introduced new function resctrl_config_cntr to assign the counter, update the bitmap and reset the architectural state.
Taken care of error handling(freeing the counter) when assignment fails.
Changed rdtgroup_assign_cntrs() and rdtgroup_unassign_cntrs() to return void. Updated couple of rdtgroup_unassign_cntrs() calls properly.
Fixed problem changing the mode to mbm_cntr_assign mode when it is not supported. Added extra checks to detect if systems supports it.
https://lore.kernel.org/lkml/[email protected]/
As discussed in the above comment, introduced resctrl_mon_event_config_set to handle IPI. But sending another IPI inside IPI causes problem. Kernel reports SMP warning. So, introduced resctrl_arch_update_cntr() to send the command directly.
Fixed handling special case '//0=' and '//".
Removed extra strstr() call in rdtgroup_mbm_assign_control_write(). Added generic failure text when assignment operation fails. Corrected user documentation format texts.
v8:
Patches are getting into final stages.
Couple of changes Patch 8, Patch 19 and Patch 23.
Most of the other changes are related to rename and text message updates.
Details are in each patch. Here is the summary.
Added __init attribute to dom_data_init() in patch 8/25. Moved the mbm_cntrs_init() and mbm_cntrs_exit() functionality inside dom_data_init() and dom_data_exit() respectively.
Renamed resctrl_mbm_evt_config_init() to arch_mbm_evt_config_init() Renamed resctrl_arch_event_config_get() to resctrl_arch_mon_event_config_get().
resctrl_arch_event_config_set() to resctrl_arch_mon_event_config_set().
Rename resctrl_arch_assign_cntr to resctrl_arch_config_cntr. Renamed rdtgroup_assign_cntr() to rdtgroup_assign_cntr_event(). Added the code to return the error if rdtgroup_assign_cntr_event fails. Moved definition of MBM_EVENT_ARRAY_INDEX to resctrl/internal.h. Renamed rdtgroup_mbm_cntr_is_assigned to mbm_cntr_assigned_to_domain Added return error handling in resctrl_arch_config_cntr(). Renamed rdtgroup_assign_grp to rdtgroup_assign_cntrs.
Renamed rdtgroup_unassign_grp to rdtgroup_unassign_cntrs. Fixed the problem with unassigning the child MON groups of CTRL_MON group. Reset the internal counters after mbm_cntr_assign mode is changed. Renamed rdtgroup_mbm_cntr_reset() to mbm_cntr_reset()
Renamed resctrl_arch_mbm_cntr_assign_configure to
resctrl_arch_mbm_cntr_assign_set_one.
Used the same IPI as event update to modify the assignment. Could not do the way we discussed in the thread.
https://lore.kernel.org/lkml/[email protected]/
Needed to figure out event type to update the configuration.
Moved unassign first and assign during the assign modification. Assign none "_" takes priority. Cannot be mixed with other flags. Updated the documentation and .rst file format. htmldoc looks ok.
v7:
Major changes are related to FS and arch codes separation. Changed few interface names based on feedback.
Here are the summary and each patch contains changes specific the patch.
Removed WARN_ON for num_mbm_cntrs. Decided to dynamically allocate the bitmap. WARN_ON is not required anymore.
Renamed the function resctrl_arch_get_abmc_enabled() to resctrl_arch_mbm_cntr_assign_enabled().
Merged resctrl_arch_mbm_cntr_assign_disable, resctrl_arch_mbm_cntr_assign_disable and renamed to resctrl_arch_mbm_cntr_assign_set(). Passed the struct rdt_resource to these functions.
Removed resctrl_arch_reset_rmid_all() from arch code. This will be done from FS the caller.
Updated the descriptions/commit log in resctrl.rst to generic text. Removed ABMC references. Renamed mbm_mode to mbm_assign_mode.
Renamed mbm_control to mbm_assign_control.
Introduced mutex lock in rdtgroup_mbm_mode_show().
The 'legacy' mode is called 'default' mode.
Removed the static allocation and now allocating bitmap mbm_cntr_free_map dynamically.
Merged rdtgroup_assign_cntr(), rdtgroup_alloc_cntr() into one. Merged rdtgroup_unassign_cntr(), rdtgroup_free_cntr() into one.
Added struct rdt_resource to the interface functions resctrl_arch_assign_cntr () and resctrl_arch_unassign_cntr().
Rename rdtgroup_abmc_cfg() to resctrl_abmc_config_one_amd().
Added a new patch to fix counter assignment on event config changes.
Removed the references of ABMC from user interfaces.
Simplified the parsing (strsep(&token, "//") in rdtgroup_mbm_assign_control_write(). Added mutex lock in rdtgroup_mbm_assign_control_write() while processing.
Thomas Gleixner asked us to update https://gitlab.com/x86-cpuid.org/x86-cpuid-db.
It needs internal approval. We are working on it.
v6:
We still need to finalize few interface details on mbm_assign_mode and mbm_assign_control in case of ABMC and Soft-ABMC. We can continue the discussion with this series.
Added support for domain-id '*' to update all the domains at once. Fixed assign interface to allocate the counter if counter is not assigned.
Fixed unassign interface to free the counter if the counter is not assigned in any of the domains.
Renamed abmc_capable to mbm_cntr_assignable.
Renamed abmc_enabled to mbm_cntr_assign_enabled.
Used msr_set_bit and msr_clear_bit for msr updates.
Renamed resctrl_arch_abmc_enable() to resctrl_arch_mbm_cntr_assign_enable(). Renamed resctrl_arch_abmc_disable() to resctrl_arch_mbm_cntr_assign_disable().
Changed the display name from num_cntrs to num_mbm_cntrs.
Removed the variable mbm_cntrs_free_map_len. This is not required. Removed the call mbm_cntrs_init() in arch code. This needs to be done at higher level. Used DECLARE_BITMAP to initialize mbm_cntrs_free_map.
Removed unused config value definitions.
Introduced mbm_cntr_map to track counters at domain level. With this we dont need to send MSR read to read the counter configuration.
Separated all the counter id management to upper level in FS code.
Added checks to detect "Unassigned" before reading the RMID.
More details in each patch.
v5:
Rebase changes (because of SNC support)
Interface changes.
/sys/fs/resctrl/mbm_assign to /sys/fs/resctrl/mbm_assign_mode. /sys/fs/resctrl/mbm_assign_control to /sys/fs/resctrl/mbm_assign_control.
Added few arch specific routines.
resctrl_arch_get_abmc_enabled.
resctrl_arch_abmc_enable.
resctrl_arch_abmc_disable.
Few renames
num_cntrs_free_map -> mbm_cntrs_free_map num_cntrs_init -> mbm_cntrs_init arch_domain_mbm_evt_config -> resctrl_arch_mbm_evt_config
Introduced resctrl_arch_event_config_get and
resctrl_arch_event_config_set() to update event configuration.
Removed mon_state field mongroup. Added MON_CNTR_UNSET to initialize counters.
Renamed ctr_id to cntr_id for the hardware counter.
Report "Unassigned" in case the user attempts to read the events without assigning the counter.
ABMC is enabled during the boot up. Can be enabled or disabled later.
Fixed opcode and flags combination.
'=_" is valid.
"-_" amd "+_" is not valid.Added all the comments as far as I know. If I missed something, it is not intentional.
v4:
Main change is domain specific event assignment.
Kept the ABMC feature as a default.
Dynamcic switching between ABMC and mbm_legacy is still allowed. We are still not clear about mount option.
Moved the monitoring related data in resctrl_mon structure from rdt_resource. Fixed the display of legacy and ABMC mode.
Used bimap APIs when possible.
Removed event configuration read from MSRs. We can use the internal saved data.(patch 12)
Added more comments about L3_QOS_ABMC_CFG MSR.
Added IPIs to read the assignment status for each domain (patch 18 and 19) More details in each patch.
v3:
This series adds the support for global assignment mode discussed in the thread. https://lore.kernel.org/lkml/[email protected]/
Removed the individual assignment mode and included the global assignment interface. Added following interface files.
a. /sys/fs/resctrl/info/L3_MON/mbm_assign
Used for displaying the current assignment mode and switch between ABMC and legacy mode.
b. /sys/fs/resctrl/info/L3_MON/mbm_assign_control
Used for lising the groups assignment mode and modify the assignment states.
c. Most of the changes are related to the new interface.
d. Addressed the comments from Reinette, James and Peter.
e. Hope I have addressed most of the major feedbacks discussed. If I missed
something then it is not intentional. Please feel free to comment.
f. Sending this as an RFC as per Reinette's comment. So, this is still open
for discussion.
v2:
a. Major change is the way ABMC is enabled. Earlier, user needed to remount
with -o abmc to enable ABMC feature. Removed that option now.
Now users can enable ABMC by "$echo 1 to /sys/fs/resctrl/info/L3_MON/mbm_assign_enable".
b. Added new word 21 to x86/cpufeatures.h.
c. Display unsupported if user attempts to read the events when ABMC is enabled
and event is not assigned.
d. Display monitor_state as "Unsupported" when ABMC is disabled.
e. Text updates and rebase to latest tip tree (as of Jan 18).
f. This series is still work in progress. I am yet to hear from ARM developers.
v9: https://lore.kernel.org/lkml/[email protected]/
v8: https://lore.kernel.org/lkml/[email protected]/
v7: https://lore.kernel.org/lkml/[email protected]/
v6: https://lore.kernel.org/lkml/[email protected]/
v5: https://lore.kernel.org/lkml/[email protected]/
v4: https://lore.kernel.org/lkml/[email protected]/
v3: https://lore.kernel.org/lkml/[email protected]/
v2: https://lore.kernel.org/lkml/[email protected]/
v1: https://lore.kernel.org/lkml/[email protected]/
Babu Moger (24):
x86/resctrl: Add __init attribute to functions called from
resctrl_late_init()
x86/cpufeatures: Add support for Assignable Bandwidth Monitoring
Counters (ABMC)
x86/resctrl: Add ABMC feature in the command line options x86/resctrl: Consolidate monitoring related data from rdt_resource x86/resctrl: Detect Assignable Bandwidth Monitoring feature details x86/resctrl: Introduce resctrl_file_fflags_init() to initialize fflags x86/resctrl: Add support to enable/disable AMD ABMC feature x86/resctrl: Introduce the interface to display monitor mode x86/resctrl: Introduce interface to display number of monitoring
counters
x86/resctrl: Introduce mbm_total_cfg and mbm_local_cfg in struct
rdt_hw_mon_domain
x86/resctrl: Remove MSR reading of event configuration value x86/resctrl: Introduce cntr_cfg to track assignable counters at domain x86/resctrl: Introduce interface to display number of free counters x86/resctrl: Add data structures and definitions for ABMC assignment x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter
with ABMC
x86/resctrl: Add interface to the assign counter x86/resctrl: Add the interface to unassign a counter x86/resctrl: Auto assign/unassign counters when mbm_cntr_assign is
enabled
x86/resctrl: Report "Unassigned" for MBM events in mbm_cntr_assign
mode
x86/resctrl: Introduce the interface to switch between monitor modes x86/resctrl: Configure mbm_cntr_assign mode if supported x86/resctrl: Update assignments on event configuration changes x86/resctrl: Introduce interface to list assignment states of all the
groups
x86/resctrl: Introduce interface to modify assignment states of the
groups
.../admin-guide/kernel-parameters.txt | 2 +- Documentation/arch/x86/resctrl.rst | 233 +++++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/msr-index.h | 2 + arch/x86/kernel/cpu/cpuid-deps.c | 3 + arch/x86/kernel/cpu/resctrl/core.c | 27 +- arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 8 + arch/x86/kernel/cpu/resctrl/internal.h | 78 +- arch/x86/kernel/cpu/resctrl/monitor.c | 68 +- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 971 ++++++++++++++++-- arch/x86/kernel/cpu/scattered.c | 1 + include/linux/resctrl.h | 53 +- 12 files changed, 1355 insertions(+), 92 deletions(-)
Signature · 1 line
2.34.1
Babu Moger
reviewerPATCH v10 1/24 x86/resctrl: Add __init attribute to functions called from resctrl_late_init()
resctrl_late_init() has the __init attribute, but some of the functions called from it do not have the __init attribute.
Add the __init attribute to all the functions in the call sequences to maintain consistency throughout.
---
v10: Text changes.
Added __init attribute to cache_alloc_hsw_probe() Followed function prototype rules (preferred order is storage class before return type).
v9: Moved the patch to the begining of the series.
Fixed all the call sequences. Added additional Fixed tags.
v8: New patch.
--- arch/x86/kernel/cpu/resctrl/core.c | 10 +++++----- arch/x86/kernel/cpu/resctrl/internal.h | 2 +- arch/x86/kernel/cpu/resctrl/monitor.c | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-)
arch/x86/kernel/cpu/resctrl/core.c +5 -5
@@ -145,7 +145,7 @@ u32 resctrl_arch_system_num_rmid_idx(void)* is always 20 on hsw server parts. The minimum cache bitmask length * allowed for HSW server is always 2 bits. Hardcode all of them. */ -static inline void cache_alloc_hsw_probe (void ) +static inline __init void cache_alloc_hsw_probe (void ) {struct rdt_hw_resource *hw_res = &rdt_resources_all[RDT_RESOURCE_L3 ];struct rdt_resource *r = &hw_res->r_resctrl;
@@ -275,7 +275,7 @@ static __init bool __rdt_get_mem_config_amd(struct rdt_resource *r)return true; } -static void rdt_get_cache_alloc_cfg (int idx,struct rdt_resource *r) +static __init void rdt_get_cache_alloc_cfg (int idx,struct rdt_resource *r) {struct rdt_hw_resource *hw_res =resctrl_to_arch_res (r);union cpuid_0x10_1_eax eax;
@@ -294,7 +294,7 @@ static void rdt_get_cache_alloc_cfg(int idx, struct rdt_resource *r) r->alloc_capable = true; } -static void rdt_get_cdp_config (int level) +static __init void rdt_get_cdp_config (int level) {/* * By default, CDP is disabled. CDP can be enabled by mount parameter
@@ -304,12 +304,12 @@ static void rdt_get_cdp_config(int level) rdt_resources_all[level].r_resctrl.cdp_capable = true; } -static void rdt_get_cdp_l3_config (void ) +static __init void rdt_get_cdp_l3_config (void ) {rdt_get_cdp_config (RDT_RESOURCE_L3 ); } -static void rdt_get_cdp_l2_config (void ) +static __init void rdt_get_cdp_l2_config (void ) {rdt_get_cdp_config (RDT_RESOURCE_L2 ); }
arch/x86/kernel/cpu/resctrl/internal.h +1 -1
@@ -627,7 +627,7 @@ int closids_supported(void);void closid_free (int closid);int alloc_rmid (u32 closid);void free_rmid (u32 closid,u32 rmid); -int rdt_get_mon_l3_config (struct rdt_resource *r); +int __init rdt_get_mon_l3_config (struct rdt_resource *r); void __exit rdt_put_mon_l3_config(void);bool __init rdt_cpu_has (int flag);void mon_event_count (void *info);
arch/x86/kernel/cpu/resctrl/monitor.c +2 -2
@@ -983,7 +983,7 @@ void mbm_setup_overflow_handler(struct rdt_mon_domain *dom, unsigned long delay_schedule_delayed_work_on (cpu, &dom->mbm_over, delay); } -static int dom_data_init (struct rdt_resource *r) +static __init int dom_data_init (struct rdt_resource *r) {u32 idx_limit =resctrl_arch_system_num_rmid_idx ();u32 num_closid =resctrl_arch_get_num_closid (r);
@@ -1081,7 +1081,7 @@ static struct mon_evt mbm_local_event = {* because as per the SDM the total and local memory bandwidth * are enumerated as part of L3 monitoring. */ -static void l3_mon_evt_init (struct rdt_resource *r) +static __init void l3_mon_evt_init (struct rdt_resource *r) {INIT_LIST_HEAD (&r->evt_list);
Signature · 1 line
2.34.1
Babu Moger
reviewerPATCH v10 2/24 x86/cpufeatures: Add support for Assignable Bandwidth Monitoring Counters (ABMC)
In reply to Babu MogerUsers can create as many monitor groups as RMIDs supported by the hardware. However, bandwidth monitoring feature on AMD system only guarantees that RMIDs currently assigned to a processor will be tracked by hardware. The counters of any other RMIDs which are no longer being tracked will be reset to zero. The MBM event counters return "Unavailable" for the RMIDs that are not tracked by hardware. So, there can be only limited number of groups that can give guaranteed monitoring numbers. With ever changing configurations there is no way to definitely know which of these groups are being tracked for certain point of time. Users do not have the option to monitor a group or set of groups for certain period of time without worrying about RMID being reset in between.
The ABMC feature provides an option to the user to assign a hardware counter to an RMID, event pair and monitor the bandwidth as long as it is assigned. The assigned RMID will be tracked by the hardware until the user unassigns it manually. There is no need to worry about counters being reset during this period. Additionally, the user can specify a bitmask identifying the specific bandwidth types from the given source to track with the counter.
Without ABMC enabled, monitoring will work in current mode without assignment option.
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 feature can be detected via CPUID_Fn80000020_EBX_x00 bit 5. Bits Description
5 ABMC (Assignable Bandwidth Monitoring Counters)
The feature details are documented in APM listed below [1].
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3.3 Assignable Bandwidth Monitoring (ABMC).
---
Note: Checkpatch checks/warnings are ignored to maintain coding style.
v10: No changes.
v9: Took care of couple of minor merge conflicts. No other changes.
v8: No changes.
v7: Removed "" from feature flags. Not required anymore.
https://lore.kernel.org/lkml/20240817145058.GCZsC40neU4wkPXeVR@fat_crate.local/
v6: Added Reinette's Reviewed-by. Moved the Checkpatch note below ---.
v5: Minor rebase change and subject line update.
v4: Changes because of rebase. Feature word 21 has few more additions now.
Changed the text to "tracked by hardware" instead of active.
v3: Change because of rebase. Actual patch did not change.
v2: Added dependency on X86_FEATURE_BMEC.
--- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/cpuid-deps.c | 3 +++ arch/x86/kernel/cpu/scattered.c | 1 + 3 files changed, 5 insertions(+)
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -479,6 +479,7 @@#define X86_FEATURE_AMD_FAST_CPPC (21*32 + 5)/* Fast CPPC */ #define X86_FEATURE_AMD_HETEROGENEOUS_CORES (21*32 + 6)/* Heterogeneous Core Topology */ #define X86_FEATURE_AMD_WORKLOAD_CLASS (21*32 + 7)/* Workload Classification */ +#define X86_FEATURE_ABMC (21*32 + 8)/* Assignable Bandwidth Monitoring Counters */ /* * BUG word(s)
arch/x86/kernel/cpu/cpuid-deps.c +3 -0
@@ -70,6 +70,9 @@ static const struct cpuid_dep cpuid_deps[] = { { X86_FEATURE_CQM_MBM_LOCAL, X86_FEATURE_CQM_LLC }, { X86_FEATURE_BMEC, X86_FEATURE_CQM_MBM_TOTAL }, { X86_FEATURE_BMEC, X86_FEATURE_CQM_MBM_LOCAL }, + { X86_FEATURE_ABMC, X86_FEATURE_CQM_MBM_TOTAL }, + { X86_FEATURE_ABMC, X86_FEATURE_CQM_MBM_LOCAL }, + { X86_FEATURE_ABMC, X86_FEATURE_BMEC }, { X86_FEATURE_AVX512_BF16, X86_FEATURE_AVX512VL }, { X86_FEATURE_AVX512_FP16, X86_FEATURE_AVX512BW }, { X86_FEATURE_ENQCMD, X86_FEATURE_XSAVES },
arch/x86/kernel/cpu/scattered.c +1 -0
@@ -49,6 +49,7 @@ static const struct cpuid_bit cpuid_bits[] = { { X86_FEATURE_MBA, CPUID_EBX, 6, 0x80000008, 0 }, { X86_FEATURE_SMBA, CPUID_EBX, 2, 0x80000020, 0 }, { X86_FEATURE_BMEC, CPUID_EBX, 3, 0x80000020, 0 }, + { X86_FEATURE_ABMC, CPUID_EBX, 5, 0x80000020, 0 }, { X86_FEATURE_AMD_WORKLOAD_CLASS, CPUID_EAX, 22, 0x80000021, 0 }, { X86_FEATURE_PERFMON_V2, CPUID_EAX, 0, 0x80000022, 0 }, { X86_FEATURE_AMD_LBR_V2, CPUID_EAX, 1, 0x80000022, 0 },
Signature · 1 line
2.34.1
Babu Moger
reviewerPATCH v10 3/24 x86/resctrl: Add ABMC feature in the command line options
In reply to Babu MogerAdd the command line option to enable or disable exposing the ABMC (Assignable Bandwidth Monitoring Counters) hardware feature to resctrl.
---
v10: No changes.
v9: No code changes. Added Reviewed-by.
v8: Commit message update.
v7: No changes
v6: No changes
v5: No changes
v4: No changes
v3: No changes
v2: No changes
--- Documentation/admin-guide/kernel-parameters.txt | 2 +- Documentation/arch/x86/resctrl.rst | 1 + arch/x86/kernel/cpu/resctrl/core.c | 2 ++ 3 files changed, 4 insertions(+), 1 deletion(-)
Documentation/admin-guide/kernel-parameters.txt +1 -1
@@ -5854,7 +5854,7 @@ rdt= [HW,X86,RDT] Turn on/off individual RDT features. List is: cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, l2cdp, - mba, smba, bmec. + mba, smba, bmec, abmc. E.g. to turn on cmt and turn off mba use: rdt=cmt,!mba
Documentation/arch/x86/resctrl.rst +1 -0
@@ -26,6 +26,7 @@ MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local" MBA (Memory Bandwidth Allocation) "mba" SMBA (Slow Memory Bandwidth Allocation) "" BMEC (Bandwidth Monitoring Event Configuration) "" +ABMC (Assignable Bandwidth Monitoring Counters) "" =============================================== ================================ Historically, new features were made visible by default in /proc/cpuinfo. This
arch/x86/kernel/cpu/resctrl/core.c +2 -0
@@ -809,6 +809,7 @@ enum {RDT_FLAG_MBA ,RDT_FLAG_SMBA ,RDT_FLAG_BMEC , + RDT_FLAG_ABMC, };#define RDT_OPT (idx, n, f) \
@@ -834,6 +835,7 @@ static struct rdt_options rdt_options[] __initdata = {RDT_OPT (RDT_FLAG_MBA ,"mba" ,X86_FEATURE_MBA ),RDT_OPT (RDT_FLAG_SMBA ,"smba" ,X86_FEATURE_SMBA ),RDT_OPT (RDT_FLAG_BMEC ,"bmec" ,X86_FEATURE_BMEC ), + RDT_OPT(RDT_FLAG_ABMC, "abmc", X86_FEATURE_ABMC), };#define NUM_RDT_OPTIONS ARRAY_SIZE(rdt_options)
Signature · 1 line
2.34.1
Babu Moger
reviewerPATCH v10 4/24 x86/resctrl: Consolidate monitoring related data from rdt_resource
In reply to Babu MogerThe cache allocation and memory bandwidth allocation feature properties are consolidated into struct resctrl_cache and struct resctrl_membw respectively.
In preparation for more monitoring properties that will clobber the existing resource struct more, re-organize the monitoring specific properties to also be in a separate structure.
---
v10: No changes.
v9: No changes.
v8: Added Reviewed-by from Reinette. No other changes.
v7: Added kernel doc for data structure. Minor text update.
v6: Update commit message and update kernel doc for rdt_resource.
v5: Commit message update.
Also changes related to data structure updates does to SNC support.
v4: New patch.
--- arch/x86/kernel/cpu/resctrl/core.c | 4 ++-- arch/x86/kernel/cpu/resctrl/monitor.c | 18 +++++++++--------- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 8 ++++---- include/linux/resctrl.h | 16 ++++++++++++---- 4 files changed, 27 insertions(+), 19 deletions(-)
arch/x86/kernel/cpu/resctrl/core.c +2 -2
@@ -124,7 +124,7 @@ u32 resctrl_arch_system_num_rmid_idx(void)struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3 ].r_resctrl;/* RMID are independent numbers for x86. num_rmid_idx == num_rmid */ -return r->num_rmid; +return r->mon.num_rmid; }/*
@@ -625,7 +625,7 @@ static void domain_add_cpu_mon(int cpu, struct rdt_resource *r)arch_mon_domain_online (r, d); -if (arch_domain_mbm_alloc (r->num_rmid, hw_dom)) { +if (arch_domain_mbm_alloc (r->mon.num_rmid, hw_dom)) {mon_domain_free (hw_dom);return ; }
arch/x86/kernel/cpu/resctrl/monitor.c +9 -9
@@ -222,7 +222,7 @@ static int logical_rmid_to_physical_rmid(int cpu, int lrmid)if (snc_nodes_per_l3_cache ==1 )return lrmid; -return lrmid + (cpu_to_node (cpu) % snc_nodes_per_l3_cache) * r->num_rmid; +return lrmid + (cpu_to_node (cpu) % snc_nodes_per_l3_cache) * r->mon.num_rmid; }static int __rmid_read_phys (u32 prmid,enum resctrl_event_id eventid,u64 *val)
@@ -297,11 +297,11 @@ void resctrl_arch_reset_rmid_all(struct rdt_resource *r, struct rdt_mon_domain *if (is_mbm_total_enabled ())memset (hw_dom->arch_mbm_total,0 , -sizeof (*hw_dom->arch_mbm_total) * r->num_rmid); +sizeof (*hw_dom->arch_mbm_total) * r->mon.num_rmid);if (is_mbm_local_enabled ())memset (hw_dom->arch_mbm_local,0 , -sizeof (*hw_dom->arch_mbm_local) * r->num_rmid); +sizeof (*hw_dom->arch_mbm_local) * r->mon.num_rmid); }static u64 mbm_overflow_count (u64 prev_msr,u64 cur_msr,unsigned int width)
@@ -1083,14 +1083,14 @@ static struct mon_evt mbm_local_event = {*/ static __init void l3_mon_evt_init (struct rdt_resource *r) { -INIT_LIST_HEAD (&r->evt_list); +INIT_LIST_HEAD (&r->mon.evt_list);if (is_llc_occupancy_enabled ()) -list_add_tail (&llc_occupancy_event.list, &r->evt_list); +list_add_tail (&llc_occupancy_event.list, &r->mon.evt_list);if (is_mbm_total_enabled ()) -list_add_tail (&mbm_total_event.list, &r->evt_list); +list_add_tail (&mbm_total_event.list, &r->mon.evt_list);if (is_mbm_local_enabled ()) -list_add_tail (&mbm_local_event.list, &r->evt_list); +list_add_tail (&mbm_local_event.list, &r->mon.evt_list); }/*
@@ -1187,7 +1187,7 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r) resctrl_rmid_realloc_limit = boot_cpu_data.x86_cache_size *1024 ; hw_res->mon_scale = boot_cpu_data.x86_cache_occ_scale / snc_nodes_per_l3_cache; - r->num_rmid = (boot_cpu_data.x86_cache_max_rmid +1 ) / snc_nodes_per_l3_cache; + r->mon.num_rmid = (boot_cpu_data.x86_cache_max_rmid +1 ) / snc_nodes_per_l3_cache; hw_res->mbm_width =MBM_CNTR_WIDTH_BASE ;if (mbm_offset >0 && mbm_offset <=MBM_CNTR_WIDTH_OFFSET_MAX )
@@ -1202,7 +1202,7 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r)* * For a 35MB LLC and 56 RMIDs, this is ~1.8% of the LLC. */ - threshold = resctrl_rmid_realloc_limit / r->num_rmid; + threshold = resctrl_rmid_realloc_limit / r->mon.num_rmid;/* * Because num_rmid may not be a power of two, round the value
arch/x86/kernel/cpu/resctrl/rdtgroup.c +4 -4
@@ -1097,7 +1097,7 @@ static int rdt_num_rmids_show(struct kernfs_open_file *of, {struct rdt_resource *r = of->kn->parent->priv; -seq_printf (seq,"%d\n" , r->num_rmid); +seq_printf (seq,"%d\n" , r->mon.num_rmid);return 0 ; }
@@ -1108,7 +1108,7 @@ static int rdt_mon_features_show(struct kernfs_open_file *of,struct rdt_resource *r = of->kn->parent->priv;struct mon_evt *mevt; -list_for_each_entry (mevt, &r->evt_list, list) { +list_for_each_entry (mevt, &r->mon.evt_list, list) {seq_printf (seq,"%s\n" , mevt->name);if (mevt->configurable)seq_printf (seq,"%s_config\n" , mevt->name);
@@ -3057,13 +3057,13 @@ static int mon_add_all_files(struct kernfs_node *kn, struct rdt_mon_domain *d,struct mon_evt *mevt;int ret; -if (WARN_ON (list_empty (&r->evt_list))) +if (WARN_ON (list_empty (&r->mon.evt_list)))return -EPERM ; priv.u.rid = r->rid; priv.u.domid = do_sum ? d->ci->id : d->hdr.id; priv.u.sum = do_sum; -list_for_each_entry (mevt, &r->evt_list, list) { +list_for_each_entry (mevt, &r->mon.evt_list, list) { priv.u.evtid = mevt->evtid; ret =mon_addfile (kn, mevt->name, priv.priv);if (ret)
include/linux/resctrl.h +12 -4
@@ -182,16 +182,26 @@ enum resctrl_scope { RESCTRL_L3_NODE, }; +/** +* struct resctrl_mon - Monitoring related data of a resctrl resource +* @num_rmid: Number of RMIDs available +* @evt_list: List of monitoring events +*/ +struct resctrl_mon { +int num_rmid; +struct list_head evt_list; +}; +/** * struct rdt_resource - attributes of a resctrl resource * @rid: The index of the resource * @alloc_capable: Is allocation available on this machine * @mon_capable: Is monitor feature available on this machine -* @num_rmid: Number of RMIDs available * @ctrl_scope: Scope of this resource for control functions * @mon_scope: Scope of this resource for monitor functions * @cache: Cache allocation related data * @membw: If the component has bandwidth controls, their properties. +* @mon: Monitoring related data. * @ctrl_domains: RCU list of all control domains for this resource * @mon_domains: RCU list of all monitor domains for this resource * @name: Name to use in "schemata" file.
@@ -199,7 +209,6 @@ enum resctrl_scope {* @default_ctrl: Specifies default cache cbm or memory B/W percent. * @format_str: Per resource format string to show domain value * @parse_ctrlval: Per resource function pointer to parse control values -* @evt_list: List of monitoring events * @fflags: flags to choose base and info files * @cdp_capable: Is the CDP feature available on this resource */
@@ -207,11 +216,11 @@ struct rdt_resource {int rid;bool alloc_capable;bool mon_capable; -int num_rmid;enum resctrl_scope ctrl_scope;enum resctrl_scope mon_scope;struct resctrl_cache cache;struct resctrl_membw membw; +struct resctrl_mon mon;struct list_head ctrl_domains;struct list_head mon_domains;char *name;
@@ -221,7 +230,6 @@ struct rdt_resource {int (*parse_ctrlval)(struct rdt_parse_data *data,struct resctrl_schema *s,struct rdt_ctrl_domain *d); -struct list_head evt_list;unsigned long fflags;bool cdp_capable; };
Signature · 1 line
2.34.1
Babu Moger
reviewerPATCH v10 5/24 x86/resctrl: Detect Assignable Bandwidth Monitoring feature details
In reply to Babu MogerABMC feature details are reported via CPUID Fn8000_0020_EBX_x5. Bits Description
15:0 MAX_ABMC Maximum Supported Assignable Bandwidth
Monitoring Counter ID + 1
The feature details are documented in APM listed below [1].
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3.3 Assignable Bandwidth Monitoring (ABMC).
Detect the feature and number of assignable monitoring counters supported.
---
v10: No changes.
v9: Added Reviewed-by tag. No code changes
v8: Used GENMASK for the mask.
v7: Removed WARN_ON for num_mbm_cntrs. Decided to dynamically allocate the
bitmap. WARN_ON is not required anymore.
Removed redundant comments.
v6: Commit message update.
Renamed abmc_capable to mbm_cntr_assignable.
v5: Name change num_cntrs to num_mbm_cntrs.
Moved abmc_capable to resctrl_mon.
v4: Removed resctrl_arch_has_abmc(). Added all the code inline. We dont
need to separate this as arch code.
v3: Removed changes related to mon_features.
Moved rdt_cpu_has to core.c and added new function resctrl_arch_has_abmc. Also moved the fields mbm_assign_capable and mbm_assign_cntrs to rdt_resource. (James)
v2: Changed the field name to mbm_assign_capable from abmc_capable.
--- arch/x86/kernel/cpu/resctrl/monitor.c | 6 ++++++ include/linux/resctrl.h | 4 ++++ 2 files changed, 10 insertions(+)
arch/x86/kernel/cpu/resctrl/monitor.c +6 -0
@@ -1230,6 +1230,12 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r) mbm_local_event.configurable = true;mbm_config_rftype_init ("mbm_local_bytes_config" ); } + +if (rdt_cpu_has (X86_FEATURE_ABMC )) { + r->mon.mbm_cntr_assignable = true; +cpuid_count (0x80000020 ,5 , &eax, &ebx, &ecx, &edx); + r->mon.num_mbm_cntrs = (ebx &GENMASK (15 ,0 )) +1 ; + } }l3_mon_evt_init (r);
include/linux/resctrl.h +4 -0
@@ -185,10 +185,14 @@ enum resctrl_scope {/** * struct resctrl_mon - Monitoring related data of a resctrl resource * @num_rmid: Number of RMIDs available +* @num_mbm_cntrs: Number of assignable monitoring counters +* @mbm_cntr_assignable:Is system capable of supporting monitor assignment? * @evt_list: List of monitoring events */ struct resctrl_mon {int num_rmid; +int num_mbm_cntrs; +bool mbm_cntr_assignable;struct list_head evt_list; };
Signature · 1 line
2.34.1
Babu Moger
reviewerPATCH v10 6/24 x86/resctrl: Introduce resctrl_file_fflags_init() to initialize fflags
In reply to Babu Mogerthread_throttle_mode_init() and mbm_config_rftype_init() both initialize fflags for resctrl files.
Adding new files will involve adding another function to initialize the fflags. This can be simplified by adding a new function resctrl_file_fflags_init() and passing the file name and flags to be initialized.
Consolidate fflags initialization into resctrl_file_fflags_init() and remove thread_throttle_mode_init() and mbm_config_rftype_init().
---
v10: No changes.
Tony added this patch in his series. Will remove it after it is merged.
https://lore.kernel.org/lkml/[email protected]/
v9: No changes.
v8: No changes.
v7: No changes.
v6: Added Reviewed-by from Reinette.
v5: Commit message update.
v4: Commit message update.
v3: New patch to display ABMC capability.
--- arch/x86/kernel/cpu/resctrl/core.c | 4 +++- arch/x86/kernel/cpu/resctrl/internal.h | 4 ++-- arch/x86/kernel/cpu/resctrl/monitor.c | 6 ++++-- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 16 +++------------- 4 files changed, 12 insertions(+), 18 deletions(-)
arch/x86/kernel/cpu/resctrl/core.c +3 -1
@@ -234,7 +234,9 @@ static __init bool __get_mem_config_intel(struct rdt_resource *r) r->membw.throttle_mode =THREAD_THROTTLE_PER_THREAD ; else r->membw.throttle_mode = THREAD_THROTTLE_MAX; -thread_throttle_mode_init (); + +resctrl_file_fflags_init ("thread_throttle_mode" , +RFTYPE_CTRL_INFO |RFTYPE_RES_MB ); r->alloc_capable = true;
arch/x86/kernel/cpu/resctrl/internal.h +2 -2
@@ -647,8 +647,8 @@ void cqm_handle_limbo(struct work_struct *work);bool has_busy_rmid (struct rdt_mon_domain *d);void __check_limbo (struct rdt_mon_domain *d,bool force_free);void rdt_domain_reconfigure_cdp (struct rdt_resource *r); -void __init thread_throttle_mode_init (void ); -void __init mbm_config_rftype_init (const char *config); +void __init resctrl_file_fflags_init (const char *config, +unsigned long fflags);void rdt_staged_configs_clear (void );bool closid_allocated (unsigned int closid);int resctrl_find_cleanest_closid (void );
arch/x86/kernel/cpu/resctrl/monitor.c +4 -2
@@ -1224,11 +1224,13 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r)if (rdt_cpu_has (X86_FEATURE_CQM_MBM_TOTAL )) { mbm_total_event.configurable = true; -mbm_config_rftype_init ("mbm_total_bytes_config" ); +resctrl_file_fflags_init ("mbm_total_bytes_config" , +RFTYPE_MON_INFO |RFTYPE_RES_CACHE ); }if (rdt_cpu_has (X86_FEATURE_CQM_MBM_LOCAL )) { mbm_local_event.configurable = true; -mbm_config_rftype_init ("mbm_local_bytes_config" ); +resctrl_file_fflags_init ("mbm_local_bytes_config" , +RFTYPE_MON_INFO |RFTYPE_RES_CACHE ); }if (rdt_cpu_has (X86_FEATURE_ABMC )) {
arch/x86/kernel/cpu/resctrl/rdtgroup.c +3 -13
@@ -2020,24 +2020,14 @@ static struct rftype *rdtgroup_get_rftype_by_name(const char *name)return NULL ; } -void __init thread_throttle_mode_init (void ) -{ -struct rftype *rft; - - rft =rdtgroup_get_rftype_by_name ("thread_throttle_mode" ); -if (!rft) -return ; - - rft->fflags =RFTYPE_CTRL_INFO |RFTYPE_RES_MB ; -} - -void __init mbm_config_rftype_init (const char *config) +void __init resctrl_file_fflags_init (const char *config, +unsigned long fflags) {struct rftype *rft; rft =rdtgroup_get_rftype_by_name (config);if (rft) - rft->fflags =RFTYPE_MON_INFO |RFTYPE_RES_CACHE ; + rft->fflags = fflags; }/**
Signature · 1 line
2.34.1
Babu Moger
reviewerPATCH v10 7/24 x86/resctrl: Add support to enable/disable AMD ABMC feature
In reply to Babu MogerAdd the functionality to enable/disable AMD ABMC feature.
AMD ABMC feature is enabled by setting enabled bit(0) in MSR L3_QOS_EXT_CFG. When the state of ABMC is changed, the MSR needs to be updated on all the logical processors in the QOS Domain.
Hardware counters will reset when ABMC state is changed.
The ABMC feature details are documented in APM listed below [1].
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3.3 Assignable Bandwidth Monitoring (ABMC).
---
v10: No changes.
v9: Re-ordered the MSR and added Reviewed-by tag.
v8: Commit message update and moved around the comments about L3_QOS_EXT_CFG
to _resctrl_abmc_enable.
v7: Renamed the function
resctrl_arch_get_abmc_enabled() to resctrl_arch_mbm_cntr_assign_enabled().
Merged resctrl_arch_mbm_cntr_assign_disable, resctrl_arch_mbm_cntr_assign_disable and renamed to resctrl_arch_mbm_cntr_assign_set().
Moved the function definition to linux/resctrl.h.
Passed the struct rdt_resource to these functions.
Removed resctrl_arch_reset_rmid_all() from arch code. This will be done from the caller.
v6: Renamed abmc_enabled to mbm_cntr_assign_enabled.
Used msr_set_bit and msr_clear_bit for msr updates.
Renamed resctrl_arch_abmc_enable() to resctrl_arch_mbm_cntr_assign_enable(). Renamed resctrl_arch_abmc_disable() to resctrl_arch_mbm_cntr_assign_disable(). Made _resctrl_abmc_enable to return void.
v5: Renamed resctrl_abmc_enable to resctrl_arch_abmc_enable.
Renamed resctrl_abmc_disable to resctrl_arch_abmc_disable. Introduced resctrl_arch_get_abmc_enabled to get abmc state from non-arch code.
Renamed resctrl_abmc_set_all to _resctrl_abmc_enable(). Modified commit log to make it clear about AMD ABMC feature.
v3: No changes.
v2: Few text changes in commit message.
--- arch/x86/include/asm/msr-index.h | 1 + arch/x86/kernel/cpu/resctrl/core.c | 5 ++++ arch/x86/kernel/cpu/resctrl/internal.h | 5 ++++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 36 ++++++++++++++++++++++++++ include/linux/resctrl.h | 3 +++ 5 files changed, 50 insertions(+)
arch/x86/include/asm/msr-index.h +1 -0
@@ -1194,6 +1194,7 @@/* - AMD: */ #define MSR_IA32_MBA_BW_BASE 0xc0000200#define MSR_IA32_SMBA_BW_BASE 0xc0000280 +#define MSR_IA32_L3_QOS_EXT_CFG 0xc00003ff#define MSR_IA32_EVT_CFG_BASE 0xc0000400/* AMD-V MSRs */
arch/x86/kernel/cpu/resctrl/core.c +5 -0
@@ -405,6 +405,11 @@ void rdt_ctrl_update(void *arg) hw_res->msr_update (m); } +bool resctrl_arch_mbm_cntr_assign_enabled (struct rdt_resource *r) +{ +return resctrl_to_arch_res (r)->mbm_cntr_assign_enabled; +} +/* * rdt_find_domain - Search for a domain id in a resource domain list. *
arch/x86/kernel/cpu/resctrl/internal.h +5 -0
@@ -56,6 +56,9 @@/* Max event bits supported */ #define MAX_EVT_CONFIG_BITS GENMASK(6, 0) +/* Setting bit 0 in L3_QOS_EXT_CFG enables the ABMC feature. */ +#define ABMC_ENABLE_BIT 0 +/** * cpumask_any_housekeeping() - Choose any CPU in @mask, preferring those that * aren't marked nohz_full
@@ -477,6 +480,7 @@ struct rdt_parse_data {* @mbm_cfg_mask: Bandwidth sources that can be tracked when Bandwidth * Monitoring Event Configuration (BMEC) is supported. * @cdp_enabled: CDP state of this resource +* @mbm_cntr_assign_enabled: ABMC feature is enabled * * Members of this structure are either private to the architecture * e.g. mbm_width, or accessed via helpers that provide abstraction. e.g.
@@ -491,6 +495,7 @@ struct rdt_hw_resource {unsigned int mbm_width;unsigned int mbm_cfg_mask;bool cdp_enabled; +bool mbm_cntr_assign_enabled; };static inline struct rdt_hw_resource *resctrl_to_arch_res (struct rdt_resource *r)
arch/x86/kernel/cpu/resctrl/rdtgroup.c +36 -0
@@ -2402,6 +2402,42 @@ int resctrl_arch_set_cdp_enabled(enum resctrl_res_level l, bool enable)return 0 ; } +static void resctrl_abmc_set_one_amd (void *arg) +{ +bool *enable = arg; + +if (*enable) +msr_set_bit (MSR_IA32_L3_QOS_EXT_CFG ,ABMC_ENABLE_BIT ); +else +msr_clear_bit (MSR_IA32_L3_QOS_EXT_CFG ,ABMC_ENABLE_BIT ); +} + +/* +* Update L3_QOS_EXT_CFG MSR on all the CPUs associated with the monitor +* domain. +*/ +static void _resctrl_abmc_enable (struct rdt_resource *r,bool enable) +{ +struct rdt_mon_domain *d; + +list_for_each_entry (d, &r->mon_domains, hdr.list) +on_each_cpu_mask (&d->hdr.cpu_mask, + resctrl_abmc_set_one_amd, &enable,1 ); +} + +int resctrl_arch_mbm_cntr_assign_set (struct rdt_resource *r,bool enable) +{ +struct rdt_hw_resource *hw_res =resctrl_to_arch_res (r); + +if (r->mon.mbm_cntr_assignable && + hw_res->mbm_cntr_assign_enabled != enable) { +_resctrl_abmc_enable (r, enable); + hw_res->mbm_cntr_assign_enabled = enable; + } + +return 0 ; +} +/* * We don't allow rdtgroup directories to be created anywhere * except the root directory. Thus when looking for the rdtgroup
include/linux/resctrl.h +3 -0
@@ -355,4 +355,7 @@ void resctrl_arch_reset_rmid_all(struct rdt_resource *r, struct rdt_mon_domain *extern unsigned int resctrl_rmid_realloc_threshold;extern unsigned int resctrl_rmid_realloc_limit; +int resctrl_arch_mbm_cntr_assign_set (struct rdt_resource *r,bool enable); +bool resctrl_arch_mbm_cntr_assign_enabled (struct rdt_resource *r); +#endif /* _RESCTRL_H */
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 07/24] x86/resctrl: Add support to enable/disable AMD ABMC feature
Hi Babu,
arch/x86/kernel/cpu/resctrl/rdtgroup.c
Quoted 5 lines · Babu Moger
static inline struct
rdt_hw_resource*resctrl_to_arch_res(structrdt_resource*r)arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0
These functions are clearly monitoring related. Is there a reason why they are in rdtgroup.c and not in monitor.c?
Quoted 48 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +36
-0@@ -2402,6 +2402,42 @@ int resctrl_arch_set_cdp_enabled(enum resctrl_res_level l, bool enable)return 0 ; } +static void resctrl_abmc_set_one_amd (void *arg) +{ +bool *enable = arg; + +if (*enable) +msr_set_bit (MSR_IA32_L3_QOS_EXT_CFG ,ABMC_ENABLE_BIT ); +else +msr_clear_bit (MSR_IA32_L3_QOS_EXT_CFG ,ABMC_ENABLE_BIT ); +} + +/* +* Update L3_QOS_EXT_CFG MSR on all the CPUs associated with the monitor +* domain. +*/ +static void _resctrl_abmc_enable (struct rdt_resource *r,bool enable) +{ +struct rdt_mon_domain *d; + +list_for_each_entry (d, &r->mon_domains, hdr.list) +on_each_cpu_mask (&d->hdr.cpu_mask, + resctrl_abmc_set_one_amd, &enable,1 ); +} + +int resctrl_arch_mbm_cntr_assign_set (struct rdt_resource *r,bool enable) +{ +struct rdt_hw_resource *hw_res =resctrl_to_arch_res (r); + +if (r->mon.mbm_cntr_assignable && + hw_res->mbm_cntr_assign_enabled != enable) { +_resctrl_abmc_enable (r, enable); + hw_res->mbm_cntr_assign_enabled = enable; + } + +return 0 ; +} +/* * We don't allow rdtgroup directories to be created anywhere * except the root directory. Thus when looking for the rdtgroup include/linux/resctrl.h +0
-0
include/linux/resctrl.h void resctrl_arch_reset_rmid_all(struct rdt_resource *r, struct rdt_mon_domain * · line 361
Quoted 7 lines
include/linux/resctrl.h +3
-0@@ -355,4 +355,7 @@ void resctrl_arch_reset_rmid_all(struct rdt_resource *r, struct rdt_mon_domain *extern unsigned int resctrl_rmid_realloc_threshold;extern unsigned int resctrl_rmid_realloc_limit; +int resctrl_arch_mbm_cntr_assign_set (struct rdt_resource *r,bool enable); +bool resctrl_arch_mbm_cntr_assign_enabled (struct rdt_resource *r); +#endif /* _RESCTRL_H */
During the software controller work Boris stated [1] that these APIs should only appear in the main header file at the time they are used. This series makes a few changes to include/linux/resctrl.h that, considering this feedback, should rather be in arch/x86/kernel/cpu/resctrl/internal.h until MPAM starts using them.
Reinette
[1] https://lore.kernel.org/all/20241209222047.GKZ1dtPxIu5_Hxs1fp@fat_crate.local/
Re: [PATCH v10 07/24] x86/resctrl: Add support to enable/disable AMD ABMC feature
Hi Reinette,
Quoted 4 lines · Reinette Chatre
Hi Babu,
On 12/12/24 12:15 PM, Babu Moger wrote:
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c
Quoted 5 lines
static inline struct
rdt_hw_resource*resctrl_to_arch_res(structrdt_resource*r)arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0These functions are clearly monitoring related. Is there a reason why they are in
rdtgroup.cand not inmonitor.c?
There is no specific reason. Most of these functions are called from user interface. User interface handlers are defined in rdtgroup.c.
All the code in this series is related to monitoring. We can move everything to monitor.c if you are ok with it.
Quoted 52 lines
Quoted 52 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +36
-0@@ -2402,6 +2402,42 @@ int resctrl_arch_set_cdp_enabled(enum resctrl_res_level l, bool enable)return 0 ; } +static void resctrl_abmc_set_one_amd (void *arg) +{ +bool *enable = arg; + +if (*enable) +msr_set_bit (MSR_IA32_L3_QOS_EXT_CFG ,ABMC_ENABLE_BIT ); +else +msr_clear_bit (MSR_IA32_L3_QOS_EXT_CFG ,ABMC_ENABLE_BIT ); +} + +/* +* Update L3_QOS_EXT_CFG MSR on all the CPUs associated with the monitor +* domain. +*/ +static void _resctrl_abmc_enable (struct rdt_resource *r,bool enable) +{ +struct rdt_mon_domain *d; + +list_for_each_entry (d, &r->mon_domains, hdr.list) +on_each_cpu_mask (&d->hdr.cpu_mask, + resctrl_abmc_set_one_amd, &enable,1 ); +} + +int resctrl_arch_mbm_cntr_assign_set (struct rdt_resource *r,bool enable) +{ +struct rdt_hw_resource *hw_res =resctrl_to_arch_res (r); + +if (r->mon.mbm_cntr_assignable && + hw_res->mbm_cntr_assign_enabled != enable) { +_resctrl_abmc_enable (r, enable); + hw_res->mbm_cntr_assign_enabled = enable; + } + +return 0 ; +} +/* * We don't allow rdtgroup directories to be created anywhere * except the root directory. Thus when looking for the rdtgroup include/linux/resctrl.h +0
-0@@ -355,4 +355,7 @@ void resctrl_arch_reset_rmid_all(struct rdt_resource *r, struct rdt_mon_domain *extern unsigned int resctrl_rmid_realloc_threshold;extern unsigned int resctrl_rmid_realloc_limit;
Quoted 10 lines
include/linux/resctrl.h void resctrl_arch_reset_rmid_all(struct rdt_resource *r, struct rdt_mon_domain * · line 361
Quoted 4 lines
include/linux/resctrl.h +3
-0+int resctrl_arch_mbm_cntr_assign_set (struct rdt_resource *r,bool enable); +bool resctrl_arch_mbm_cntr_assign_enabled (struct rdt_resource *r); +#endif /* _RESCTRL_H */ During the software controller work Boris stated [1] that these APIs should only appear in the main header file at the time they are used. This series makes a few changes to
include/linux/resctrl.hthat, considering this feedback, should rather be inarch/x86/kernel/cpu/resctrl/internal.huntil MPAM starts using them.
Sure. We can do that.
Quoted 5 lines
Reinette
[1] https://lore.kernel.org/all/20241209222047.GKZ1dtPxIu5_Hxs1fp@fat_crate.local/
Reinette Chatre
maintainerRe: [PATCH v10 07/24] x86/resctrl: Add support to enable/disable AMD ABMC feature
Hi Babu,
Quoted 16 lines · Babu
Hi Reinette,
Quoted 4 lines · Reinette Chatre
Hi Babu,
On 12/12/24 12:15 PM, Babu Moger wrote:
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c
Quoted 5 lines
static inline struct
rdt_hw_resource*resctrl_to_arch_res(structrdt_resource*r)arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0These functions are clearly monitoring related. Is there a reason why they are in
rdtgroup.cand not inmonitor.c?
Quoted 2 lines
There is no specific reason. Most of these functions are called from user interface. User interface handlers are defined in
rdtgroup.c.
Most, but not all of them, are, yes. With most operations triggered via user interface we'll end up with most code in the same file if trying to keep all code triggered by user space together.
Quoted 1 line
All the code in this series is related to monitoring. We can move everything to
monitor.cif you are ok with it.
The read/write callbacks could stay with res_common_files[] to make their definition simpler. I think it would make things clear if these callback functions call into monitoring code located in monitor.c. Since you have been staring at this much longer, please let me know if you find this to actually make things harder to follow and find.
Reinette
Babu Moger
reviewerPATCH v10 8/24 x86/resctrl: Introduce the interface to display monitor mode
In reply to Babu MogerIntroduce the interface file "mbm_assign_mode" to list monitor modes supported.
The "mbm_cntr_assign" mode provides the option to assign a counter to an RMID, event pair and monitor the bandwidth as long as it is assigned.
On AMD systems "mbm_cntr_assign" is backed by the ABMC (Assignable Bandwidth Monitoring Counters) hardware feature and is enabled by default.
The "default" mode is the existing monitoring mode that works without the explicit counter assignment, instead relying on dynamic counter assignment by hardware that may result in hardware not dedicating a counter resulting in monitoring data reads returning "Unavailable".
Provide an interface to display the monitor mode on the system.
$ cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode [mbm_cntr_assign] default
---
v10: Added few more text to user documentation clarify on the default mode.
v9: Updated user documentation based on comments.
v8: Commit message update.
v7: Updated the descriptions/commit log in resctrl.rst to generic text.
Thanks to James and Reinette.
Rename mbm_mode to mbm_assign_mode.
Introduced mutex lock in rdtgroup_mbm_mode_show().
v6: Added documentation for mbm_cntr_assign and legacy mode.
Moved mbm_mode fflags initialization to static initialization.
v5: Changed interface name to mbm_mode.
It will be always available even if ABMC feature is not supported. Added description in resctrl.rst about ABMC mode.
Fixed display abmc and legacy consistantly.
v4: Fixed the checks for legacy and abmc mode. Default it ABMC.
v3: New patch to display ABMC capability.
--- Documentation/arch/x86/resctrl.rst | 33 ++++++++++++++++++++++++++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 31 ++++++++++++++++++++++++ 2 files changed, 64 insertions(+)
Documentation/arch/x86/resctrl.rst +33 -0
@@ -257,6 +257,39 @@ with the following files: # cat /sys/fs/resctrl/info/L3_MON/mbm_local_bytes_config 0=0x30;1=0x30;3=0x15;4=0x15 +"mbm_assign_mode": + Reports the list of monitoring modes supported. The enclosed brackets + indicate which mode is enabled. + :: + + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode + [mbm_cntr_assign] + default + + "mbm_cntr_assign": + + In mbm_cntr_assign mode user-space is able to specify which of the + events in CTRL_MON or MON groups should have a counter assigned using the + "mbm_assign_control" file. The number of counters available is described + in the "num_mbm_cntrs" file. Changing the mode may cause all counters on + a resource to reset. + + The mode is useful on AMD platforms which support more CTRL_MON and MON + groups than hardware counters, meaning 'unassigned' events on CTRL_MON or + MON groups will report 'Unavailable'. + + AMD Platforms with ABMC (Assignable Bandwidth Monitoring Counters) feature + enable this mode by default so that counters remain assigned even when the + corresponding RMID is not in use by any processor. + + "default": + + In default mode, resctrl assumes there is a hardware counter for each + event within every CTRL_MON and MON group. On AMD platforms, it is + recommended to use mbm_cntr_assign mode if supported, because reading + "mbm_total_bytes" or "mbm_local_bytes" will report 'Unavailable' if + there is no counter associated with that event. + "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancy
arch/x86/kernel/cpu/resctrl/rdtgroup.c +31 -0
@@ -845,6 +845,30 @@ static int rdtgroup_rmid_show(struct kernfs_open_file *of,return ret; } +static int rdtgroup_mbm_assign_mode_show (struct kernfs_open_file *of, +struct seq_file *s,void *v) +{ +struct rdt_resource *r = of->kn->parent->priv; + +mutex_lock (&rdtgroup_mutex); + +if (r->mon.mbm_cntr_assignable) { +if (resctrl_arch_mbm_cntr_assign_enabled (r)) { +seq_puts (s,"[mbm_cntr_assign]\n" ); +seq_puts (s,"default\n" ); + }else { +seq_puts (s,"mbm_cntr_assign\n" ); +seq_puts (s,"[default]\n" ); + } + }else { +seq_puts (s,"[default]\n" ); + } + +mutex_unlock (&rdtgroup_mutex); + +return 0 ; +} +#ifdef CONFIG_PROC_CPU_RESCTRL /*
@@ -1901,6 +1925,13 @@ static struct rftype res_common_files[] = { .seq_show = mbm_local_bytes_config_show, .write = mbm_local_bytes_config_write, }, + { + .name = "mbm_assign_mode", + .mode = 0444, + .kf_ops = &rdtgroup_kf_single_ops, + .seq_show = rdtgroup_mbm_assign_mode_show, + .fflags = RFTYPE_MON_INFO, + }, { .name = "cpus", .mode = 0644,
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 08/24] x86/resctrl: Introduce the interface to display monitor mode
Hi Babu,
Quoted 57 lines · Babu Moger
Introduce the interface file "
mbm_assign_mode" to list monitor modes supported.The "
mbm_cntr_assign" mode provides the option to assign a counter to an RMID, event pair and monitor the bandwidth as long as it is assigned.On AMD systems "
mbm_cntr_assign" is backed by the ABMC (Assignable Bandwidth Monitoring Counters) hardware feature and is enabled by default.The "default" mode is the existing monitoring mode that works without the explicit counter assignment, instead relying on dynamic counter assignment by hardware that may result in hardware not dedicating a counter resulting in monitoring data reads returning "Unavailable".
Provide an interface to display the monitor mode on the system.
$ cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode [mbm_cntr_assign] defaultSigned-off-by Babu Moger <[email protected]>---
v10: Added few more text to user documentation clarify on the default mode.v9: Updated user documentation based on comments.
v8: Commit message update.
v7: Updated the descriptions/commit log in
resctrl.rstto generic text.
Thanks to James and Reinette.
Renamembm_modetombm_assign_mode.
Introduced mutex lock inrdtgroup_mbm_mode_show().v6: Added documentation for
mbm_cntr_assignand legacy mode.
Movedmbm_modefflags initialization to static initialization.v5: Changed interface name to
mbm_mode.
It will be always available even if ABMC feature is not supported. Added description inresctrl.rstabout ABMC mode.
Fixed display abmc and legacy consistantly.v4: Fixed the checks for legacy and abmc mode. Default it ABMC.
v3: New patch to display ABMC capability.
--- Documentation/arch/x86/resctrl.rst | 33 ++++++++++++++++++++++++++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 31 ++++++++++++++++++++++++ 2 files changed, 64 insertions(+)Documentation/arch/x86/resctrl.rst +1
-0@@ -257,6 +257,39 @@ with the following files: # cat /sys/fs/resctrl/info/L3_MON/mbm_local_bytes_config 0=0x30;1=0x30;3=0x15;4=0x15 +"mbm_assign_mode":
Documentation/arch/x86/resctrl.rst with the following files: · line 270
Quoted 10 lines
Documentation/arch/x86/resctrl.rst +10
-0+ Reports the list of monitoring modes supported. The enclosed brackets + indicate which mode is enabled. + :: + + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode + [mbm_cntr_assign] + default + + "mbm_cntr_assign": +
The text below jumps into usage with assumption that user space already understands the feature. How about starting with some context? Something like "A monitoring event can only accumulate data while it is backed by a hardware counter."
Documentation/arch/x86/resctrl.rst with the following files: · line 279
Quoted 9 lines
Documentation/arch/x86/resctrl.rst +9
-0+ In mbm_cntr_assign mode user-space is able to specify which of the + events in CTRL_MON or MON groups should have a counter assigned using the + "mbm_assign_control" file. The number of counters available is described + in the "num_mbm_cntrs" file. Changing the mode may cause all counters on + a resource to reset. + + The mode is useful on AMD platforms which support more CTRL_MON and MON + groups than hardware counters, meaning 'unassigned' events on CTRL_MON or + MON groups will report 'Unavailable'.
The "meaning 'unassigned'" is not clear to me since in "mbm_cntr_assign" mode these events will (at end of this series) actually return "Unassigned", no? Perhaps this portion can be dropped for now and the text found in patch #20 about returning "Unassigned" can be placed here instead ... but this should probably be done in patch #19 that adds that capability.
Quoted 21 lines
Documentation/arch/x86/resctrl.rst +13
-0+ + AMD Platforms with ABMC (Assignable Bandwidth Monitoring Counters) feature + enable this mode by default so that counters remain assigned even when the + corresponding RMID is not in use by any processor. + + "default": + + In default mode, resctrl assumes there is a hardware counter for each + event within every CTRL_MON and MON group. On AMD platforms, it is + recommended to use mbm_cntr_assign mode if supported, because reading + "mbm_total_bytes" or "mbm_local_bytes" will report 'Unavailable' if + there is no counter associated with that event. + "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancyarch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_rmid_show(struct kernfs_open_file *of, · line 849
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0@@ -845,6 +845,30 @@ static int rdtgroup_rmid_show(struct kernfs_open_file *of,return ret; } +static int rdtgroup_mbm_assign_mode_show (struct kernfs_open_file *of, +struct seq_file *s,void *v)
I remember this topic from earlier version yet I still see many instances of the "rdtgroup_" namespace used for functions that do not interact with resource groups. Could you please check this series and fix this?
Quoted 29 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +22
-0+{ +struct rdt_resource *r = of->kn->parent->priv; + +mutex_lock (&rdtgroup_mutex); + +if (r->mon.mbm_cntr_assignable) { +if (resctrl_arch_mbm_cntr_assign_enabled (r)) { +seq_puts (s,"[mbm_cntr_assign]\n" ); +seq_puts (s,"default\n" ); + }else { +seq_puts (s,"mbm_cntr_assign\n" ); +seq_puts (s,"[default]\n" ); + } + }else { +seq_puts (s,"[default]\n" ); + } + +mutex_unlock (&rdtgroup_mutex); + +return 0 ; +} +#ifdef CONFIG_PROC_CPU_RESCTRL /* @@ -1901,6 +1925,13 @@ static struct rftype res_common_files[] = { .seq_show = mbm_local_bytes_config_show, .write = mbm_local_bytes_config_write, },
arch/x86/kernel/cpu/resctrl/rdtgroup.c static struct rftype res_common_files[] = { · line 1937
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +7
-0+ { + .name = "mbm_assign_mode", + .mode = 0444, + .kf_ops = &rdtgroup_kf_single_ops, + .seq_show = rdtgroup_mbm_assign_mode_show, + .fflags = RFTYPE_MON_INFO, + }, { .name = "cpus", .mode = 0644,
Reinette
Re: [PATCH v10 08/24] x86/resctrl: Introduce the interface to display monitor mode
Hi Reinette.
Quoted 59 lines · Reinette Chatre
Hi Babu,
Quoted 56 lines · Babu Moger
Introduce the interface file "
mbm_assign_mode" to list monitor modes supported.The "
mbm_cntr_assign" mode provides the option to assign a counter to an RMID, event pair and monitor the bandwidth as long as it is assigned.On AMD systems "
mbm_cntr_assign" is backed by the ABMC (Assignable Bandwidth Monitoring Counters) hardware feature and is enabled by default.The "default" mode is the existing monitoring mode that works without the explicit counter assignment, instead relying on dynamic counter assignment by hardware that may result in hardware not dedicating a counter resulting in monitoring data reads returning "Unavailable".
Provide an interface to display the monitor mode on the system.
$ cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode [mbm_cntr_assign] defaultSigned-off-by Babu Moger <[email protected]>---
v10: Added few more text to user documentation clarify on the default mode.v9: Updated user documentation based on comments.
v8: Commit message update.
v7: Updated the descriptions/commit log in
resctrl.rstto generic text.
Thanks to James and Reinette.
Renamembm_modetombm_assign_mode.
Introduced mutex lock inrdtgroup_mbm_mode_show().v6: Added documentation for
mbm_cntr_assignand legacy mode.
Movedmbm_modefflags initialization to static initialization.v5: Changed interface name to
mbm_mode.
It will be always available even if ABMC feature is not supported. Added description inresctrl.rstabout ABMC mode.
Fixed display abmc and legacy consistantly.v4: Fixed the checks for legacy and abmc mode. Default it ABMC.
v3: New patch to display ABMC capability.
--- Documentation/arch/x86/resctrl.rst | 33 ++++++++++++++++++++++++++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 31 ++++++++++++++++++++++++ 2 files changed, 64 insertions(+)Documentation/arch/x86/resctrl.rst +0
-0@@ -257,6 +257,39 @@ with the following files: # cat /sys/fs/resctrl/info/L3_MON/mbm_local_bytes_config 0=0x30;1=0x30;3=0x15;4=0x15
Quoted 16 lines
Documentation/arch/x86/resctrl.rst with the following files: · line 270
Quoted 11 lines
Documentation/arch/x86/resctrl.rst +11
-0+"mbm_assign_mode": + Reports the list of monitoring modes supported. The enclosed brackets + indicate which mode is enabled. + :: + + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode + [mbm_cntr_assign] + default + + "mbm_cntr_assign": +The text below jumps into usage with assumption that user space already understands the feature. How about starting with some context? Something like "A monitoring event can only accumulate data while it is backed by a hardware counter."
sure.
Quoted 13 lines
Documentation/arch/x86/resctrl.rst with the following files: · line 279
Quoted 10 lines
Documentation/arch/x86/resctrl.rst +9
-0+ In mbm_cntr_assign mode user-space is able to specify which of the + events in CTRL_MON or MON groups should have a counter assigned using the + "mbm_assign_control" file. The number of counters available is described + in the "num_mbm_cntrs" file. Changing the mode may cause all counters on + a resource to reset. + + The mode is useful on AMD platforms which support more CTRL_MON and MON + groups than hardware counters, meaning 'unassigned' events on CTRL_MON or + MON groups will report 'Unavailable'.The "meaning 'unassigned'" is not clear to me since in "
mbm_cntr_assign" mode these events will (at end of this series) actually return "Unassigned", no? Perhaps
Yes. It will report "Unassigned".
Quoted 3 lines
this portion can be dropped for now and the text found in patch #20 about returning "Unassigned" can be placed here instead ... but this should probably be done in patch #19 that adds that capability.
Sure. We can do that.
Quoted 25 lines
Quoted 25 lines
Documentation/arch/x86/resctrl.rst +13
-0+ + AMD Platforms with ABMC (Assignable Bandwidth Monitoring Counters) feature + enable this mode by default so that counters remain assigned even when the + corresponding RMID is not in use by any processor. + + "default": + + In default mode, resctrl assumes there is a hardware counter for each + event within every CTRL_MON and MON group. On AMD platforms, it is + recommended to use mbm_cntr_assign mode if supported, because reading + "mbm_total_bytes" or "mbm_local_bytes" will report 'Unavailable' if + there is no counter associated with that event. + "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancyarch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -845,6 +845,30 @@ static int rdtgroup_rmid_show(struct kernfs_open_file *of,return ret; }
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_rmid_show(struct kernfs_open_file *of, · line 849
Quoted 2 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0+static int rdtgroup_mbm_assign_mode_show (struct kernfs_open_file *of, +struct seq_file *s,void *v)I remember this topic from earlier version yet I still see many instances of the "
rdtgroup_" namespace used for functions that do not interact with resource groups. Could you please check this series and fix this?
Yes. Sure. I will check on this.
Quoted 45 lines
Quoted 30 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +22
-0+{ +struct rdt_resource *r = of->kn->parent->priv; + +mutex_lock (&rdtgroup_mutex); + +if (r->mon.mbm_cntr_assignable) { +if (resctrl_arch_mbm_cntr_assign_enabled (r)) { +seq_puts (s,"[mbm_cntr_assign]\n" ); +seq_puts (s,"default\n" ); + }else { +seq_puts (s,"mbm_cntr_assign\n" ); +seq_puts (s,"[default]\n" ); + } + }else { +seq_puts (s,"[default]\n" ); + } + +mutex_unlock (&rdtgroup_mutex); + +return 0 ; +} +#ifdef CONFIG_PROC_CPU_RESCTRL /* @@ -1901,6 +1925,13 @@ static struct rftype res_common_files[] = { .seq_show = mbm_local_bytes_config_show, .write = mbm_local_bytes_config_write, },arch/x86/kernel/cpu/resctrl/rdtgroup.c static struct rftype res_common_files[] = { · line 1937
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +7
-0+ { + .name = "mbm_assign_mode", + .mode = 0444, + .kf_ops = &rdtgroup_kf_single_ops, + .seq_show = rdtgroup_mbm_assign_mode_show, + .fflags = RFTYPE_MON_INFO, + }, { .name = "cpus", .mode = 0644,Reinette
Babu Moger
reviewerPATCH v10 9/24 x86/resctrl: Introduce interface to display number of monitoring counters
In reply to Babu MogerThe mbm_cntr_assign mode provides an option to the user to assign a counter to an RMID, event pair and monitor the bandwidth as long as the counter is assigned. Number of assignments depend on number of monitoring counters available.
Provide the interface to display the number of monitoring counters supported. The interface file 'num_mbm_cntrs' is available when an architecture supports mbm_cntr_assign mode.
---
v10: No changes.
v9: Updated user document based on the comments.
Will add a new file available_mbm_cntrs later in the series.
v8: Commit message update and documentation update.
v7: Minor commit log text changes.
v6: No changes.
v5: Changed the display name from num_cntrs to num_mbm_cntrs.
Updated the commit message.
Moved the patch after mbm_mode is introduced.
v4: Changed the counter name to num_cntrs. And few text changes.
v3: Changed the field name to mbm_assign_cntrs.
v2: Changed the field name to mbm_assignable_counters from abmc_counter.
---
--- Documentation/arch/x86/resctrl.rst | 12 ++++++++++++ arch/x86/kernel/cpu/resctrl/monitor.c | 1 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 16 ++++++++++++++++ 3 files changed, 29 insertions(+)
Documentation/arch/x86/resctrl.rst +12 -0
@@ -290,6 +290,18 @@ with the following files: "mbm_total_bytes" or "mbm_local_bytes" will report 'Unavailable' if there is no counter associated with that event. +"num_mbm_cntrs": + The number of monitoring counters available for assignment when the + architecture supports mbm_cntr_assign mode. + + The resctrl file system supports tracking up to two memory bandwidth + events per monitoring group: mbm_total_bytes and/or mbm_local_bytes. + Up to two counters can be assigned per monitoring group, one for each + memory bandwidth event. More monitoring groups can be tracked by + assigning one counter per monitoring group. However, doing so limits + memory bandwidth tracking to a single memory bandwidth event per + monitoring group. + "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancy
arch/x86/kernel/cpu/resctrl/monitor.c +1 -0
@@ -1237,6 +1237,7 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r) r->mon.mbm_cntr_assignable = true;cpuid_count (0x80000020 ,5 , &eax, &ebx, &ecx, &edx); r->mon.num_mbm_cntrs = (ebx &GENMASK (15 ,0 )) +1 ; +resctrl_file_fflags_init ("num_mbm_cntrs" ,RFTYPE_MON_INFO ); } }
arch/x86/kernel/cpu/resctrl/rdtgroup.c +16 -0
@@ -869,6 +869,16 @@ static int rdtgroup_mbm_assign_mode_show(struct kernfs_open_file *of,return 0 ; } +static int rdtgroup_num_mbm_cntrs_show (struct kernfs_open_file *of, +struct seq_file *s,void *v) +{ +struct rdt_resource *r = of->kn->parent->priv; + +seq_printf (s,"%d\n" , r->mon.num_mbm_cntrs); + +return 0 ; +} +#ifdef CONFIG_PROC_CPU_RESCTRL /*
@@ -1940,6 +1950,12 @@ static struct rftype res_common_files[] = { .seq_show = rdtgroup_cpus_show, .fflags = RFTYPE_BASE, }, + { + .name = "num_mbm_cntrs", + .mode = 0444, + .kf_ops = &rdtgroup_kf_single_ops, + .seq_show = rdtgroup_num_mbm_cntrs_show, + }, { .name = "cpus_list", .mode = 0644,
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 09/24] x86/resctrl: Introduce interface to display number of monitoring counters
Hi Babu,
Quoted 8 lines · Babu Moger
The
mbm_cntr_assignmode provides an option to the user to assign a counter to an RMID, event pair and monitor the bandwidth as long as the counter is assigned. Number of assignments depend on number of monitoring counters available.Provide the interface to display the number of monitoring counters supported. The interface file '
num_mbm_cntrs' is available when an architecture supportsmbm_cntr_assignmode.
How about: "The resctrl file 'num_mbm_cntrs' is visible to user space when the system supports mbm_cntr_assign mode." ?
Quoted 35 lines
Signed-off-by Babu Moger <[email protected]>---
v10: No changes.v9: Updated user document based on the comments.
Will add a new fileavailable_mbm_cntrslater in the series.v8: Commit message update and documentation update.
v7: Minor commit log text changes.
v6: No changes.
v5: Changed the display name from
num_cntrstonum_mbm_cntrs.
Updated the commit message.
Moved the patch aftermbm_modeis introduced.v4: Changed the counter name to
num_cntrs. And few text changes.v3: Changed the field name to
mbm_assign_cntrs.v2: Changed the field name to
mbm_assignable_countersfromabmc_counter.
------ Documentation/arch/x86/resctrl.rst | 12 ++++++++++++ arch/x86/kernel/cpu/resctrl/monitor.c | 1 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 16 ++++++++++++++++ 3 files changed, 29 insertions(+)Documentation/arch/x86/resctrl.rst +0
-0
Documentation/arch/x86/resctrl.rst with the following files: · line 295
Quoted 6 lines
Documentation/arch/x86/resctrl.rst +3
-0@@ -290,6 +290,18 @@ with the following files: "mbm_total_bytes" or "mbm_local_bytes" will report 'Unavailable' if there is no counter associated with that event. +"num_mbm_cntrs": + The number of monitoring counters available for assignment when the + architecture supports mbm_cntr_assign mode.
"architecture supports" -> "system supports"
Quoted 29 lines
Documentation/arch/x86/resctrl.rst +9
-0+ + The resctrl file system supports tracking up to two memory bandwidth + events per monitoring group: mbm_total_bytes and/or mbm_local_bytes. + Up to two counters can be assigned per monitoring group, one for each + memory bandwidth event. More monitoring groups can be tracked by + assigning one counter per monitoring group. However, doing so limits + memory bandwidth tracking to a single memory bandwidth event per + monitoring group. + "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancyarch/x86/kernel/cpu/resctrl/monitor.c +1
-0@@ -1237,6 +1237,7 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r) r->mon.mbm_cntr_assignable = true;cpuid_count (0x80000020 ,5 , &eax, &ebx, &ecx, &edx); r->mon.num_mbm_cntrs = (ebx &GENMASK (15 ,0 )) +1 ; +resctrl_file_fflags_init ("num_mbm_cntrs" ,RFTYPE_MON_INFO ); } }arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_mbm_assign_mode_show(struct kernfs_open_file *of, · line 873
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0@@ -869,6 +869,16 @@ static int rdtgroup_mbm_assign_mode_show(struct kernfs_open_file *of,return 0 ; } +static int rdtgroup_num_mbm_cntrs_show (struct kernfs_open_file *of, +struct seq_file *s,void *v)
No rdtgroup_ namespace, this can be resctrl_
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_mbm_assign_mode_show(struct kernfs_open_file *of, · line 884
Quoted 11 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +8
-0+{ +struct rdt_resource *r = of->kn->parent->priv; + +seq_printf (s,"%d\n" , r->mon.num_mbm_cntrs); + +return 0 ; +} +#ifdef CONFIG_PROC_CPU_RESCTRL /*
Reinette
Re: [PATCH v10 09/24] x86/resctrl: Introduce interface to display number of monitoring counters
Hi Reinette,
Quoted 8 lines · Reinette Chatre
Hi Babu,
Quoted 5 lines · Babu Moger
The
mbm_cntr_assignmode provides an option to the user to assign a counter to an RMID, event pair and monitor the bandwidth as long as the counter is assigned. Number of assignments depend on number of monitoring counters available.
Quoted 6 lines
Quoted 3 lines
Provide the interface to display the number of monitoring counters supported. The interface file '
num_mbm_cntrs' is available when an architecture supportsmbm_cntr_assignmode.How about: "The resctrl file '
num_mbm_cntrs' is visible to user space when the system supportsmbm_cntr_assignmode." ?
Sure.
Quoted 39 lines
Quoted 39 lines
Signed-off-by Babu Moger <[email protected]>---
v10: No changes.v9: Updated user document based on the comments.
Will add a new fileavailable_mbm_cntrslater in the series.v8: Commit message update and documentation update.
v7: Minor commit log text changes.
v6: No changes.
v5: Changed the display name from
num_cntrstonum_mbm_cntrs.
Updated the commit message.
Moved the patch aftermbm_modeis introduced.v4: Changed the counter name to
num_cntrs. And few text changes.v3: Changed the field name to
mbm_assign_cntrs.v2: Changed the field name to
mbm_assignable_countersfromabmc_counter.
------ Documentation/arch/x86/resctrl.rst | 12 ++++++++++++ arch/x86/kernel/cpu/resctrl/monitor.c | 1 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 16 ++++++++++++++++ 3 files changed, 29 insertions(+)Documentation/arch/x86/resctrl.rst +0
-0@@ -290,6 +290,18 @@ with the following files: "mbm_total_bytes" or "mbm_local_bytes" will report 'Unavailable' if there is no counter associated with that event.
Quoted 5 lines
Documentation/arch/x86/resctrl.rst with the following files: · line 295
Quoted 3 lines
Documentation/arch/x86/resctrl.rst +3
-0+"num_mbm_cntrs": + The number of monitoring counters available for assignment when the + architecture supports mbm_cntr_assign mode."architecture supports" -> "system supports"
Sure.
Quoted 33 lines
Quoted 33 lines
Documentation/arch/x86/resctrl.rst +9
-0+ + The resctrl file system supports tracking up to two memory bandwidth + events per monitoring group: mbm_total_bytes and/or mbm_local_bytes. + Up to two counters can be assigned per monitoring group, one for each + memory bandwidth event. More monitoring groups can be tracked by + assigning one counter per monitoring group. However, doing so limits + memory bandwidth tracking to a single memory bandwidth event per + monitoring group. + "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancyarch/x86/kernel/cpu/resctrl/monitor.c +1
-0@@ -1237,6 +1237,7 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r) r->mon.mbm_cntr_assignable = true;cpuid_count (0x80000020 ,5 , &eax, &ebx, &ecx, &edx); r->mon.num_mbm_cntrs = (ebx &GENMASK (15 ,0 )) +1 ; +resctrl_file_fflags_init ("num_mbm_cntrs" ,RFTYPE_MON_INFO ); } }arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -869,6 +869,16 @@ static int rdtgroup_mbm_assign_mode_show(struct kernfs_open_file *of,return 0 ; }
Quoted 4 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_mbm_assign_mode_show(struct kernfs_open_file *of, · line 873
Quoted 2 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0+static int rdtgroup_num_mbm_cntrs_show (struct kernfs_open_file *of, +struct seq_file *s,void *v)No
rdtgroup_namespace, this can beresctrl_
Yes. Sure.
thanks
Babu
Quoted 16 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_mbm_assign_mode_show(struct kernfs_open_file *of, · line 884
Quoted 12 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +8
-0+{ +struct rdt_resource *r = of->kn->parent->priv; + +seq_printf (s,"%d\n" , r->mon.num_mbm_cntrs); + +return 0 ; +} +#ifdef CONFIG_PROC_CPU_RESCTRL /* Reinette
Babu Moger
reviewerPATCH v10 10/24 x86/resctrl: Introduce mbm_total_cfg and mbm_local_cfg in struct rdt_hw_mon_domain
In reply to Babu MogerIf the BMEC (Bandwidth Monitoring Event Configuration) feature is supported, the bandwidth events can be configured to track specific events. The event configuration is domain specific. ABMC (Assignable Bandwidth Monitoring Counters) feature needs event configuration information to assign a hardware counter to an RMID. Event configurations are not stored in resctrl but instead always read from or written to hardware directly when prompted by user space.
Read the event configuration from the hardware during the domain initialization. Save the configuration value in struct rdt_hw_mon_domain, so it can be used for counter assignment.
---
v10: Conflicts due to code displacement. Actual code didnt change.
v9: Added Reviewed-by tag. No other changes.
v8: Renamed resctrl_mbm_evt_config_init() to arch_mbm_evt_config_init()
Minor commit message update.
v7: Fixed initializing INVALID_CONFIG_VALUE to mbm_local_cfg in case of error.
v6: Renamed resctrl_arch_mbm_evt_config -> resctrl_mbm_evt_config_init
Initialized value to INVALID_CONFIG_VALUE if it is not configurable. Minor commit message update.
v5: Exported mon_event_config_index_get.
Renamed arch_domain_mbm_evt_config to resctrl_arch_mbm_evt_config.
v4: Read the configuration information from the hardware to initialize.
Added few commit messages.
Fixed the tab spaces.
v3: Minor changes related to rebase in mbm_config_write_domain.
v2: No changes.
--- arch/x86/kernel/cpu/resctrl/core.c | 2 ++ arch/x86/kernel/cpu/resctrl/internal.h | 9 +++++++++ arch/x86/kernel/cpu/resctrl/monitor.c | 26 ++++++++++++++++++++++++++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 4 +--- 4 files changed, 38 insertions(+), 3 deletions(-)
arch/x86/kernel/cpu/resctrl/core.c +2 -0
@@ -632,6 +632,8 @@ static void domain_add_cpu_mon(int cpu, struct rdt_resource *r)arch_mon_domain_online (r, d); +arch_mbm_evt_config_init (hw_dom); +if (arch_domain_mbm_alloc (r->mon.num_rmid, hw_dom)) {mon_domain_free (hw_dom);return ;
arch/x86/kernel/cpu/resctrl/internal.h +9 -0
@@ -56,6 +56,9 @@/* Max event bits supported */ #define MAX_EVT_CONFIG_BITS GENMASK(6, 0) +#define INVALID_CONFIG_VALUE U32_MAX +#define INVALID_CONFIG_INDEX UINT_MAX +/* Setting bit 0 in L3_QOS_EXT_CFG enables the ABMC feature. */ #define ABMC_ENABLE_BIT 0
@@ -401,6 +404,8 @@ struct rdt_hw_ctrl_domain {* @d_resctrl: Properties exposed to the resctrl file system * @arch_mbm_total: arch private state for MBM total bandwidth * @arch_mbm_local: arch private state for MBM local bandwidth +* @mbm_total_cfg: MBM total bandwidth configuration +* @mbm_local_cfg: MBM local bandwidth configuration * * Members of this structure are accessed via helpers that provide abstraction. */
@@ -408,6 +413,8 @@ struct rdt_hw_mon_domain {struct rdt_mon_domain d_resctrl;struct arch_mbm_state *arch_mbm_total;struct arch_mbm_state *arch_mbm_local; +u32 mbm_total_cfg; +u32 mbm_local_cfg; };static inline struct rdt_hw_ctrl_domain *resctrl_to_arch_ctrl_dom (struct rdt_ctrl_domain *r)
@@ -657,5 +664,7 @@ void __init resctrl_file_fflags_init(const char *config,void rdt_staged_configs_clear (void );bool closid_allocated (unsigned int closid);int resctrl_find_cleanest_closid (void ); +void arch_mbm_evt_config_init (struct rdt_hw_mon_domain *hw_dom); +unsigned int mon_event_config_index_get (u32 evtid);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */
arch/x86/kernel/cpu/resctrl/monitor.c +26 -0
@@ -1248,6 +1248,32 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r)return 0 ; } +void arch_mbm_evt_config_init (struct rdt_hw_mon_domain *hw_dom) +{ +unsigned int index; +u64 msrval; + +/* +* Read the configuration registers QOS_EVT_CFG_n, where <n> is +* the BMEC event number (EvtID). +*/ +if (mbm_total_event.configurable) { + index =mon_event_config_index_get (QOS_L3_MBM_TOTAL_EVENT_ID ); +rdmsrl (MSR_IA32_EVT_CFG_BASE + index, msrval); + hw_dom->mbm_total_cfg = msrval &MAX_EVT_CONFIG_BITS ; + }else { + hw_dom->mbm_total_cfg =INVALID_CONFIG_VALUE ; + } + +if (mbm_local_event.configurable) { + index =mon_event_config_index_get (QOS_L3_MBM_LOCAL_EVENT_ID ); +rdmsrl (MSR_IA32_EVT_CFG_BASE + index, msrval); + hw_dom->mbm_local_cfg = msrval &MAX_EVT_CONFIG_BITS ; + }else { + hw_dom->mbm_local_cfg =INVALID_CONFIG_VALUE ; + } +} + void __exit rdt_put_mon_l3_config(void) {dom_data_exit ();
arch/x86/kernel/cpu/resctrl/rdtgroup.c +1 -3
@@ -1582,8 +1582,6 @@ struct mon_config_info {u32 mon_config; }; -#define INVALID_CONFIG_INDEX UINT_MAX -/** * mon_event_config_index_get - get the hardware index for the * configurable event
@@ -1593,7 +1591,7 @@ struct mon_config_info {* 1 for evtid == QOS_L3_MBM_LOCAL_EVENT_ID * INVALID_CONFIG_INDEX for invalid evtid */ -static inline unsigned int mon_event_config_index_get (u32 evtid) +unsigned int mon_event_config_index_get (u32 evtid) {switch (evtid) {case QOS_L3_MBM_TOTAL_EVENT_ID :
Signature · 1 line
2.34.1
Babu Moger
reviewerPATCH v10 11/24 x86/resctrl: Remove MSR reading of event configuration value
In reply to Babu MogerThe event configuration is domain specific and initialized during domain initialization. The values are stored in struct rdt_hw_mon_domain.
It is not required to read the configuration register every time user asks for it. Use the value stored in struct rdt_hw_mon_domain instead.
Introduce resctrl_arch_mon_event_config_get() and resctrl_arch_mon_event_config_set() to get/set architecture domain specific mbm_total_cfg/mbm_local_cfg values.
---
v10: Moved the mon_config_info structure definition to resctrl.h.
v9: Removed QOS_L3_OCCUP_EVENT_ID switch case in resctrl_arch_mon_event_config_set.
Fixed a unnecessary space.
v8: Renamed
resctrl_arch_event_config_get() to resctrl_arch_mon_event_config_get(). resctrl_arch_event_config_set() to resctrl_arch_mon_event_config_set().
v7: Removed check if (val == INVALID_CONFIG_VALUE) as resctrl_arch_event_config_get
already prints warning.
Kept the Event config value definitions as is.
v6: Fixed inconstancy with types. Made all the types to u32 for config
value.
Removed few rdt_last_cmd_puts as it is not necessary. Removed unused config value definitions.
Few more updates to commit message.
v5: Introduced resctrl_arch_event_config_get and
resctrl_arch_event_config_get() based on our discussion.
https://lore.kernel.org/lkml/[email protected]/
v4: New patch.
--- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 105 +++++++++++++------------ include/linux/resctrl.h | 16 ++++ 2 files changed, 72 insertions(+), 49 deletions(-)
arch/x86/kernel/cpu/resctrl/rdtgroup.c +56 -49
@@ -1577,10 +1577,51 @@ static int rdtgroup_size_show(struct kernfs_open_file *of,return ret; } -struct mon_config_info { -u32 evtid; -u32 mon_config; -}; +u32 resctrl_arch_mon_event_config_get (struct rdt_mon_domain *d, +enum resctrl_event_id eventid) +{ +struct rdt_hw_mon_domain *hw_dom =resctrl_to_arch_mon_dom (d); + +switch (eventid) { +case QOS_L3_OCCUP_EVENT_ID : +break ; +case QOS_L3_MBM_TOTAL_EVENT_ID : +return hw_dom->mbm_total_cfg; +case QOS_L3_MBM_LOCAL_EVENT_ID : +return hw_dom->mbm_local_cfg; + } + +/* Never expect to get here */ +WARN_ON_ONCE (1 ); + +return INVALID_CONFIG_VALUE ; +} + +void resctrl_arch_mon_event_config_set (void *info) +{ +struct mon_config_info *mon_info = info; +struct rdt_hw_mon_domain *hw_dom; +unsigned int index; + + index =mon_event_config_index_get (mon_info->evtid); +if (index ==INVALID_CONFIG_INDEX ) +return ; + +wrmsr (MSR_IA32_EVT_CFG_BASE + index, mon_info->mon_config,0 ); + + hw_dom =resctrl_to_arch_mon_dom (mon_info->d); + +switch (mon_info->evtid) { +case QOS_L3_MBM_TOTAL_EVENT_ID : + hw_dom->mbm_total_cfg = mon_info->mon_config; +break ; +case QOS_L3_MBM_LOCAL_EVENT_ID : + hw_dom->mbm_local_cfg = mon_info->mon_config; +break ; +default : +break ; + } +}/** * mon_event_config_index_get - get the hardware index for the
@@ -1604,33 +1645,11 @@ unsigned int mon_event_config_index_get(u32 evtid) } } -static void mon_event_config_read (void *info) -{ -struct mon_config_info *mon_info = info; -unsigned int index; -u64 msrval; - - index =mon_event_config_index_get (mon_info->evtid); -if (index ==INVALID_CONFIG_INDEX ) { -pr_warn_once ("Invalid event id %d\n" , mon_info->evtid); -return ; - } -rdmsrl (MSR_IA32_EVT_CFG_BASE + index, msrval); - -/* Report only the valid event configuration bits */ - mon_info->mon_config = msrval &MAX_EVT_CONFIG_BITS ; -} - -static void mondata_config_read (struct rdt_mon_domain *d,struct mon_config_info *mon_info) -{ -smp_call_function_any (&d->hdr.cpu_mask, mon_event_config_read, mon_info,1 ); -} -static int mbm_config_show (struct seq_file *s,struct rdt_resource *r,u32 evtid) { -struct mon_config_info mon_info;struct rdt_mon_domain *dom;bool sep = false; +u32 val;cpus_read_lock ();mutex_lock (&rdtgroup_mutex);
@@ -1639,11 +1658,8 @@ static int mbm_config_show(struct seq_file *s, struct rdt_resource *r, u32 evtidif (sep)seq_puts (s,";" ); -memset (&mon_info,0 ,sizeof (struct mon_config_info )); - mon_info.evtid = evtid; -mondata_config_read (dom, &mon_info); - -seq_printf (s,"%d=0x%02x" , dom->hdr.id, mon_info.mon_config); + val =resctrl_arch_mon_event_config_get (dom, evtid); +seq_printf (s,"%d=0x%02x" , dom->hdr.id, val); sep = true; }seq_puts (s,"\n" );
@@ -1674,33 +1690,23 @@ static int mbm_local_bytes_config_show(struct kernfs_open_file *of,return 0 ; } -static void mon_event_config_write (void *info) -{ -struct mon_config_info *mon_info = info; -unsigned int index; - - index =mon_event_config_index_get (mon_info->evtid); -if (index ==INVALID_CONFIG_INDEX ) { -pr_warn_once ("Invalid event id %d\n" , mon_info->evtid); -return ; - } -wrmsr (MSR_IA32_EVT_CFG_BASE + index, mon_info->mon_config,0 ); -}static void mbm_config_write_domain (struct rdt_resource *r,struct rdt_mon_domain *d,u32 evtid,u32 val) {struct mon_config_info mon_info = {0 }; +u32 config_val;/* -* Read the current config value first. If both are the same then +* Check the current config value first. If both are the same then * no need to write it again. */ - mon_info.evtid = evtid; -mondata_config_read (d, &mon_info); -if (mon_info.mon_config == val) + config_val =resctrl_arch_mon_event_config_get (d, evtid); +if (config_val ==INVALID_CONFIG_VALUE || config_val == val)return ; + mon_info.d = d; + mon_info.evtid = evtid; mon_info.mon_config = val;/*
@@ -1709,7 +1715,8 @@ static void mbm_config_write_domain(struct rdt_resource *r,* are scoped at the domain level. Writing any of these MSRs * on one CPU is observed by all the CPUs in the domain. */ -smp_call_function_any (&d->hdr.cpu_mask, mon_event_config_write, +smp_call_function_any (&d->hdr.cpu_mask, + resctrl_arch_mon_event_config_set, &mon_info,1 );/*
include/linux/resctrl.h +16 -0
@@ -118,6 +118,18 @@ struct rdt_mon_domain {int cqm_work_cpu; }; +/** +* struct mon_config_info - Monitoring event configuratiin details +* @d: Domain for the event +* @evtid: Event type +* @mon_config: Event configuration value +*/ +struct mon_config_info { +struct rdt_mon_domain *d; +enum resctrl_event_id evtid; +u32 mon_config; +}; +/** * struct resctrl_cache - Cache allocation related data * @cbm_len: Length of the cache bit mask
@@ -352,6 +364,10 @@ void resctrl_arch_reset_rmid(struct rdt_resource *r, struct rdt_mon_domain *d,*/ void resctrl_arch_reset_rmid_all (struct rdt_resource *r,struct rdt_mon_domain *d); +void resctrl_arch_mon_event_config_set (void *info); +u32 resctrl_arch_mon_event_config_get (struct rdt_mon_domain *d, +enum resctrl_event_id eventid); +extern unsigned int resctrl_rmid_realloc_threshold;extern unsigned int resctrl_rmid_realloc_limit;
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 11/24] x86/resctrl: Remove MSR reading of event configuration value
Hi Babu,
Quoted 22 lines · Babu Moger
arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-18@@ -1604,33 +1645,11 @@ unsigned int mon_event_config_index_get(u32 evtid) } } -static void mon_event_config_read (void *info) -{ -struct mon_config_info *mon_info = info; -unsigned int index; -u64 msrval; - - index =mon_event_config_index_get (mon_info->evtid); -if (index ==INVALID_CONFIG_INDEX ) { -pr_warn_once ("Invalid event id %d\n" , mon_info->evtid); -return ; - } -rdmsrl (MSR_IA32_EVT_CFG_BASE + index, msrval); - -/* Report only the valid event configuration bits */ - mon_info->mon_config = msrval &MAX_EVT_CONFIG_BITS ; -} - -static void mondata_config_read (struct rdt_mon_domain *d,struct mon_config_info *mon_info)
arch/x86/kernel/cpu/resctrl/rdtgroup.c unsigned int mon_event_config_index_get(u32 evtid) · line 1652
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +1
-5-{ -smp_call_function_any (&d->hdr.cpu_mask, mon_event_config_read, mon_info,1 ); -} -static int mbm_config_show (struct seq_file *s,struct rdt_resource *r,u32 evtid) { -struct mon_config_info mon_info;struct rdt_mon_domain *dom;bool sep = false; +u32 val;
Could this variable name be more descriptive? For example, mon_config, or config_val as used in mbm_config_write_domain()?
...
include/linux/resctrl.h struct rdt_mon_domain { · line 122
Quoted 10 lines
include/linux/resctrl.h +2
-0@@ -118,6 +118,18 @@ struct rdt_mon_domain {int cqm_work_cpu; }; +/** +* struct mon_config_info - Monitoring event configuratiin details
configuratiin -> configuration
... but actually, the motivation for moving this struct here was to make it available for an arch to interpret the data passed via resctrl_arch_mon_event_config_set(). This patch passes data in this struct but a later patch modifies resctrl_arch_mon_event_config_set() to not use struct anymore ... and then leaves struct mon_config_info here.
Even so, considering Boris's preference this is no longer needed.
Quoted 14 lines
include/linux/resctrl.h +10
-0+* @d: Domain for the event +* @evtid: Event type +* @mon_config: Event configuration value +*/ +struct mon_config_info { +struct rdt_mon_domain *d; +enum resctrl_event_id evtid; +u32 mon_config; +}; +/** * struct resctrl_cache - Cache allocation related data * @cbm_len: Length of the cache bit mask
include/linux/resctrl.h void resctrl_arch_reset_rmid(struct rdt_resource *r, struct rdt_mon_domain *d, · line 370
Quoted 7 lines
include/linux/resctrl.h +4
-0@@ -352,6 +364,10 @@ void resctrl_arch_reset_rmid(struct rdt_resource *r, struct rdt_mon_domain *d,*/ void resctrl_arch_reset_rmid_all (struct rdt_resource *r,struct rdt_mon_domain *d); +void resctrl_arch_mon_event_config_set (void *info); +u32 resctrl_arch_mon_event_config_get (struct rdt_mon_domain *d, +enum resctrl_event_id eventid); +
Please move to internal header file instead and consider this for all changes to include/linux/resctrl.h
include/linux/resctrl.h void resctrl_arch_reset_rmid(struct rdt_resource *r, struct rdt_mon_domain *d, · line 373
Quoted 3 lines
include/linux/resctrl.h +0
-0extern unsigned int resctrl_rmid_realloc_threshold;extern unsigned int resctrl_rmid_realloc_limit;
Reinette
Re: [PATCH v10 11/24] x86/resctrl: Remove MSR reading of event configuration value
Hi Reinette,
Quoted 31 lines · Reinette Chatre
Hi Babu,
Quoted 27 lines · Babu Moger
arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-22@@ -1604,33 +1645,11 @@ unsigned int mon_event_config_index_get(u32 evtid) } } -static void mon_event_config_read (void *info) -{ -struct mon_config_info *mon_info = info; -unsigned int index; -u64 msrval; - - index =mon_event_config_index_get (mon_info->evtid); -if (index ==INVALID_CONFIG_INDEX ) { -pr_warn_once ("Invalid event id %d\n" , mon_info->evtid); -return ; - } -rdmsrl (MSR_IA32_EVT_CFG_BASE + index, msrval); - -/* Report only the valid event configuration bits */ - mon_info->mon_config = msrval &MAX_EVT_CONFIG_BITS ; -} - -static void mondata_config_read (struct rdt_mon_domain *d,struct mon_config_info *mon_info) -{ -smp_call_function_any (&d->hdr.cpu_mask, mon_event_config_read, mon_info,1 ); -} -static int mbm_config_show (struct seq_file *s,struct rdt_resource *r,u32 evtid)
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c unsigned int mon_event_config_index_get(u32 evtid) · line 1652
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +1
-1{ -struct mon_config_info mon_info;struct rdt_mon_domain *dom;bool sep = false; +u32 val;Could this variable name be more descriptive? For example,
mon_config, orconfig_valas used inmbm_config_write_domain()?
Will change it to config_val.
Quoted 11 lines
...
Quoted 8 lines
include/linux/resctrl.h +0
-0@@ -118,6 +118,18 @@ struct rdt_mon_domain {int cqm_work_cpu; };
Quoted 4 lines
include/linux/resctrl.h struct rdt_mon_domain { · line 122
Quoted 2 lines
include/linux/resctrl.h +2
-0+/** +* struct mon_config_info - Monitoring event configuratiin details configuratiin -> configuration
Sure.
Quoted 9 lines
... but actually, the motivation for moving this struct here was to make it available for an arch to interpret the data passed via
resctrl_arch_mon_event_config_set(). This patch passes data in this struct but a later patch modifiesresctrl_arch_mon_event_config_set()to not use struct anymore ... and then leaves structmon_config_infohere.Even so, considering Boris's preference this is no longer needed.
ok. I will move the "struct mon_config_info" definition where it is used(rdtgroup.c).
Quoted 18 lines
Quoted 18 lines
include/linux/resctrl.h +10
-0+* @d: Domain for the event +* @evtid: Event type +* @mon_config: Event configuration value +*/ +struct mon_config_info { +struct rdt_mon_domain *d; +enum resctrl_event_id evtid; +u32 mon_config; +}; +/** * struct resctrl_cache - Cache allocation related data * @cbm_len: Length of the cache bit mask @@ -352,6 +364,10 @@ void resctrl_arch_reset_rmid(struct rdt_resource *r, struct rdt_mon_domain *d,*/ void resctrl_arch_reset_rmid_all (struct rdt_resource *r,struct rdt_mon_domain *d);
Quoted 7 lines
include/linux/resctrl.h void resctrl_arch_reset_rmid(struct rdt_resource *r, struct rdt_mon_domain *d, · line 370
Quoted 4 lines
include/linux/resctrl.h +4
-0+void resctrl_arch_mon_event_config_set (void *info); +u32 resctrl_arch_mon_event_config_get (struct rdt_mon_domain *d, +enum resctrl_event_id eventid); +Please move to internal header file instead and consider this for all changes to
include/linux/resctrl.h
Sure. Thanks
Babu
Babu Moger
reviewerPATCH v10 12/24 x86/resctrl: Introduce cntr_cfg to track assignable counters at domain
In reply to Babu MogerIn mbm_assign_mode, the MBM counters are assigned/unassigned to an RMID, event pair in a resctrl group and monitor the bandwidth as long as it is assigned. Counters are assigned/unassigned at domain level and needs to be tracked at domain level.
Add the mbm_assign_cntr_cfg data structure to struct rdt_ctrl_domain to manage and track MBM counter assignments at the domain level.
---
v10: Patch changed completely to handle the counters at domain level.
https://lore.kernel.org/lkml/CALPaoCj+zWq1vkHVbXYP0znJbe6Ke3PXPWjtri5AFgD9cQDCUg@mail.gmail.com/
Removed Reviewed-by tag.
Did not see the need to add cntr_id in mbm_state structure. Not used in the code.
v9: Added Reviewed-by tag. No other changes.
v8: Minor commit message changes.
v7: Added check mbm_cntr_assignable for allocating bitmap mbm_cntr_map
v6: New patch to add domain level assignment.
--- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 11 +++++++++++ include/linux/resctrl.h | 12 ++++++++++++ 2 files changed, 23 insertions(+)
arch/x86/kernel/cpu/resctrl/rdtgroup.c +11 -0
@@ -4068,6 +4068,7 @@ static void __init rdtgroup_setup_default(void)static void domain_destroy_mon_state (struct rdt_mon_domain *d) { +kfree (d->cntr_cfg);bitmap_free (d->rmid_busy_llc);kfree (d->mbm_total);kfree (d->mbm_local);
@@ -4141,6 +4142,16 @@ static int domain_setup_mon_state(struct rdt_resource *r, struct rdt_mon_domainreturn -ENOMEM ; } } +if (is_mbm_enabled () && r->mon.mbm_cntr_assignable) { + tsize =sizeof (*d->cntr_cfg); + d->cntr_cfg =kcalloc (r->mon.num_mbm_cntrs, tsize,GFP_KERNEL ); +if (!d->cntr_cfg) { +bitmap_free (d->rmid_busy_llc); +kfree (d->mbm_total); +kfree (d->mbm_local); +return -ENOMEM ; + } + }return 0 ; }
include/linux/resctrl.h +12 -0
@@ -94,6 +94,16 @@ struct rdt_ctrl_domain {u32 *mbps_val; }; +/** +* struct mbm_cntr_cfg -Assignable counter configuration +* @evtid: Event type +* @rdtgroup: Resctrl group assigned to the counter +*/ +struct mbm_cntr_cfg { +enum resctrl_event_id evtid; +struct rdtgroup *rdtgrp; +}; +/** * struct rdt_mon_domain - group of CPUs sharing a resctrl monitor resource * @hdr: common header for different domain types
@@ -105,6 +115,7 @@ struct rdt_ctrl_domain {* @cqm_limbo: worker to periodically read CQM h/w counters * @mbm_work_cpu: worker CPU for MBM h/w counters * @cqm_work_cpu: worker CPU for CQM h/w counters +* @cntr_cfg: Assignable counters configuration */ struct rdt_mon_domain {struct rdt_domain_hdr hdr;
@@ -116,6 +127,7 @@ struct rdt_mon_domain {struct delayed_work cqm_limbo;int mbm_work_cpu;int cqm_work_cpu; +struct mbm_cntr_cfg *cntr_cfg; };/**
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 12/24] x86/resctrl: Introduce cntr_cfg to track assignable counters at domain
Hi Babu,
Did subject intend to use name of new struct?
Quoted 6 lines · Babu Moger
In
mbm_assign_mode, the MBM counters are assigned/unassigned to an RMID, event pair in a resctrl group and monitor the bandwidth as long as it is assigned. Counters are assigned/unassigned at domain level and needs to be tracked at domain level.Add the
mbm_assign_cntr_cfgdata structure to structrdt_ctrl_domainto
"mbm_assign_cntr_cfg" -> "mbm_cntr_cfg"
Quoted 1 line
manage and track MBM counter assignments at the domain level.
This can really use some more information about this data structure. I think it will be helpful to provide more information about how the data structure looks ... for example, that it is an array indexed by counter ID where the assignment details of each counter is stored. I also think it will be helpful to describe how interactions with this data structure works, that a NULL rdtgrp means that the counter is free and that it is not possible to find a counter from a resource group and arrays need to be searched instead and doing so is ok for $REASON (when considering the number of RMID and domain combinations possible on AMD). A lot is left for the reader to figure out.
Quoted 55 lines
Suggested-by Peter Newman <[email protected]>Signed-off-by Babu Moger <[email protected]>---
v10: Patch changed completely to handle the counters at domain level.
https://lore.kernel.org/lkml/CALPaoCj+zWq1vkHVbXYP0znJbe6Ke3PXPWjtri5AFgD9cQDCUg@mail.gmail.com/
Removed Reviewed-by tag.
Did not see the need to addcntr_idinmbm_statestructure. Not used in the code.v9: Added Reviewed-by tag. No other changes.
v8: Minor commit message changes.
v7: Added check
mbm_cntr_assignablefor allocating bitmapmbm_cntr_mapv6: New patch to add domain level assignment.
--- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 11 +++++++++++ include/linux/resctrl.h | 12 ++++++++++++ 2 files changed, 23 insertions(+)arch/x86/kernel/cpu/resctrl/rdtgroup.c +11
-0@@ -4068,6 +4068,7 @@ static void __init rdtgroup_setup_default(void)static void domain_destroy_mon_state (struct rdt_mon_domain *d) { +kfree (d->cntr_cfg);bitmap_free (d->rmid_busy_llc);kfree (d->mbm_total);kfree (d->mbm_local);@@ -4141,6 +4142,16 @@ static int domain_setup_mon_state(struct rdt_resource *r, struct rdt_mon_domainreturn -ENOMEM ; } } +if (is_mbm_enabled () && r->mon.mbm_cntr_assignable) { + tsize =sizeof (*d->cntr_cfg); + d->cntr_cfg =kcalloc (r->mon.num_mbm_cntrs, tsize,GFP_KERNEL ); +if (!d->cntr_cfg) { +bitmap_free (d->rmid_busy_llc); +kfree (d->mbm_total); +kfree (d->mbm_local); +return -ENOMEM ; + } + }return 0 ; }include/linux/resctrl.h +0
-0
include/linux/resctrl.h struct rdt_ctrl_domain { · line 98
Quoted 5 lines
include/linux/resctrl.h +2
-0@@ -94,6 +94,16 @@ struct rdt_ctrl_domain {u32 *mbps_val; }; +/** +* struct mbm_cntr_cfg -Assignable counter configuration
Please compare with style use in rest of the file. For example, "-Assignable" -> "- assignable"
include/linux/resctrl.h struct rdt_ctrl_domain { · line 99
Quoted 1 line
include/linux/resctrl.h +1
-0+* @evtid: Event type
This description is not useful. Consider: "MBM event to which the counter is assigned. Only valid if @rdtgroup is not NULL." (This was the first thing that came to my mind, please improve)
include/linux/resctrl.h struct rdt_ctrl_domain { · line 100
Quoted 1 line
include/linux/resctrl.h +1
-0+* @rdtgroup: Resctrl group assigned to the counter
Can add "NULL if counter is free"
Quoted 10 lines
include/linux/resctrl.h +6
-0+*/ +struct mbm_cntr_cfg { +enum resctrl_event_id evtid; +struct rdtgroup *rdtgrp; +}; +/** * struct rdt_mon_domain - group of CPUs sharing a resctrl monitor resource * @hdr: common header for different domain types
include/linux/resctrl.h struct rdt_ctrl_domain { · line 118
Quoted 4 lines
include/linux/resctrl.h +1
-0@@ -105,6 +115,7 @@ struct rdt_ctrl_domain {* @cqm_limbo: worker to periodically read CQM h/w counters * @mbm_work_cpu: worker CPU for MBM h/w counters * @cqm_work_cpu: worker CPU for CQM h/w counters +* @cntr_cfg: Assignable counters configuration
Match capitalization of surrounding text.
Will be helpful to add that this is an array indexed by counter ID.
include/linux/resctrl.h struct rdt_mon_domain { · line 133
Quoted 11 lines
include/linux/resctrl.h +1
-0*/ struct rdt_mon_domain {struct rdt_domain_hdr hdr;@@ -116,6 +127,7 @@ struct rdt_mon_domain {struct delayed_work cqm_limbo;int mbm_work_cpu;int cqm_work_cpu; +struct mbm_cntr_cfg *cntr_cfg; };/**
Reinette
Re: [PATCH v10 12/24] x86/resctrl: Introduce cntr_cfg to track assignable counters at domain
Hi Reinette,
Quoted 3 lines · Reinette Chatre
Hi Babu,
Did subject intend to use name of new struct?
Yes. Will change it to "mbm_cntr_cfg.
Quoted 10 lines · Babu Moger
Quoted 6 lines
In
mbm_assign_mode, the MBM counters are assigned/unassigned to an RMID, event pair in a resctrl group and monitor the bandwidth as long as it is assigned. Counters are assigned/unassigned at domain level and needs to be tracked at domain level.Add the
mbm_assign_cntr_cfgdata structure to structrdt_ctrl_domainto"
mbm_assign_cntr_cfg" -> "mbm_cntr_cfg"
Sure.
Quoted 12 lines
Quoted 2 lines
manage and track MBM counter assignments at the domain level.
This can really use some more information about this data structure. I think it will be helpful to provide more information about how the data structure looks ... for example, that it is an array indexed by counter ID where the assignment details of each counter is stored. I also think it will be helpful to describe how interactions with this data structure works, that a NULL rdtgrp means that the counter is free and that it is not possible to find a counter from a resource group and arrays need to be searched instead and doing so is ok for $REASON (when considering the number of RMID and domain combinations possible on AMD). A lot is left for the reader to figure out.
How about this?
In mbm_assign_mode, the MBM counters are assigned/unassigned to an RMID, event pair in a resctrl group and monitor the bandwidth as long as it is assigned. Counters are assigned/unassigned at domain level and needs to be tracked at domain level.
Add the mbm_cntr_cfg data structure to struct rdt_ctrl_domain to manage and track MBM counter assignments at the domain level.
Each domain will contain num_mbm_cntrs entries, indexed by cntr_id. During initialization, all entries will be set to zero. When a counter is allocated, its corresponding entry will be populated with the assigned struct rdtgroup and enum resctrl_event_id. When the counter is released, its entry will be reset to zero.
Quoted 58 lines
Quoted 58 lines
Suggested-by Peter Newman <[email protected]>Signed-off-by Babu Moger <[email protected]>---
v10: Patch changed completely to handle the counters at domain level.
https://lore.kernel.org/lkml/CALPaoCj+zWq1vkHVbXYP0znJbe6Ke3PXPWjtri5AFgD9cQDCUg@mail.gmail.com/
Removed Reviewed-by tag.
Did not see the need to addcntr_idinmbm_statestructure. Not used in the code.v9: Added Reviewed-by tag. No other changes.
v8: Minor commit message changes.
v7: Added check
mbm_cntr_assignablefor allocating bitmapmbm_cntr_mapv6: New patch to add domain level assignment.
--- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 11 +++++++++++ include/linux/resctrl.h | 12 ++++++++++++ 2 files changed, 23 insertions(+)arch/x86/kernel/cpu/resctrl/rdtgroup.c +11
-0@@ -4068,6 +4068,7 @@ static void __init rdtgroup_setup_default(void)static void domain_destroy_mon_state (struct rdt_mon_domain *d) { +kfree (d->cntr_cfg);bitmap_free (d->rmid_busy_llc);kfree (d->mbm_total);kfree (d->mbm_local);@@ -4141,6 +4142,16 @@ static int domain_setup_mon_state(struct rdt_resource *r, struct rdt_mon_domainreturn -ENOMEM ; } } +if (is_mbm_enabled () && r->mon.mbm_cntr_assignable) { + tsize =sizeof (*d->cntr_cfg); + d->cntr_cfg =kcalloc (r->mon.num_mbm_cntrs, tsize,GFP_KERNEL ); +if (!d->cntr_cfg) { +bitmap_free (d->rmid_busy_llc); +kfree (d->mbm_total); +kfree (d->mbm_local); +return -ENOMEM ; + } + }return 0 ; }include/linux/resctrl.h +0
-0@@ -94,6 +94,16 @@ struct rdt_ctrl_domain {u32 *mbps_val; };
Quoted 5 lines
include/linux/resctrl.h struct rdt_ctrl_domain { · line 98
Quoted 2 lines
include/linux/resctrl.h +2
-0+/** +* struct mbm_cntr_cfg -Assignable counter configuration Please compare with style use in rest of the file. For example, "-Assignable" -> "- assignable"
Sure.
Quoted 10 lines
include/linux/resctrl.h struct rdt_ctrl_domain { · line 99
Quoted 2 lines
include/linux/resctrl.h +1
-0+* @evtid: Event type This description is not useful. Consider: "MBM event to which the counter is assigned. Only valid if @rdtgroup is not NULL." (This was the first thing that came to my mind, please improve)
include/linux/resctrl.h struct rdt_ctrl_domain { · line 100
Quoted 1 line
include/linux/resctrl.h +1
-0+* @rdtgroup: Resctrl group assigned to the counter Can add "NULL if counter is free"
Sure.
Quoted 10 lines
Quoted 10 lines
include/linux/resctrl.h +6
-0+*/ +struct mbm_cntr_cfg { +enum resctrl_event_id evtid; +struct rdtgroup *rdtgrp; +}; +/** * struct rdt_mon_domain - group of CPUs sharing a resctrl monitor resource * @hdr: common header for different domain types
Quoted 8 lines
include/linux/resctrl.h struct rdt_ctrl_domain { · line 118
Quoted 5 lines
include/linux/resctrl.h +1
-0@@ -105,6 +115,7 @@ struct rdt_ctrl_domain {* @cqm_limbo: worker to periodically read CQM h/w counters * @mbm_work_cpu: worker CPU for MBM h/w counters * @cqm_work_cpu: worker CPU for CQM h/w counters +* @cntr_cfg: Assignable counters configuration Match capitalization of surrounding text.
Will be helpful to add that this is an array indexed by counter ID.
ok. Sure.
Quoted 15 lines
include/linux/resctrl.h struct rdt_mon_domain { · line 133
Quoted 12 lines
include/linux/resctrl.h +1
-0*/ struct rdt_mon_domain {struct rdt_domain_hdr hdr;@@ -116,6 +127,7 @@ struct rdt_mon_domain {struct delayed_work cqm_limbo;int mbm_work_cpu;int cqm_work_cpu; +struct mbm_cntr_cfg *cntr_cfg; };/** Reinette
Reinette Chatre
maintainerRe: [PATCH v10 12/24] x86/resctrl: Introduce cntr_cfg to track assignable counters at domain
Hi Babu,
Quoted 34 lines · Babu
Quoted 9 lines · Reinette Chatre
Quoted 6 lines · Babu Moger
In
mbm_assign_mode, the MBM counters are assigned/unassigned to an RMID, event pair in a resctrl group and monitor the bandwidth as long as it is assigned. Counters are assigned/unassigned at domain level and needs to be tracked at domain level.Add the
mbm_assign_cntr_cfgdata structure to structrdt_ctrl_domainto"
mbm_assign_cntr_cfg" -> "mbm_cntr_cfg"Sure.
Quoted 12 lines
Quoted 2 lines
manage and track MBM counter assignments at the domain level.
This can really use some more information about this data structure. I think it will be helpful to provide more information about how the data structure looks ... for example, that it is an array indexed by counter ID where the assignment details of each counter is stored. I also think it will be helpful to describe how interactions with this data structure works, that a NULL rdtgrp means that the counter is free and that it is not possible to find a counter from a resource group and arrays need to be searched instead and doing so is ok for $REASON (when considering the number of RMID and domain combinations possible on AMD). A lot is left for the reader to figure out.
How about this?
In
mbm_assign_mode, the MBM counters are assigned/unassigned to an RMID, event pair in a resctrl group and monitor the bandwidth as long as it is assigned. Counters are assigned/unassigned at domain level and needs to be tracked at domain level.
Quoted 4 lines
Add the
mbm_cntr_cfgdata structure to structrdt_ctrl_domainto manage and track MBM counter assignments at the domain level.Each domain will contain
num_mbm_cntrsentries, indexed bycntr_id. During initialization, all entries will be set to zero. When a counter is allocated, its corresponding entry will be populated with the assigned struct rdtgroup and enumresctrl_event_id. When the counter is released, its entry will be reset to zero.
It will be better if you take a step back and create a coherent changelog instead of appending independent text snippets. What you present has the same mistake as before (mbm_assign_mode vs mbm_cntr_assign mode) and does not address all the points raised.
Consider something like below (please check, improve, and complete):
In mbm_cntr_assign mode hardware counters are assigned/unassigned to an MBM event of a monitor group. Hardware counters are assigned/unassigned at monitoring domain level.
Manage a monitoring domain's hardware counters using a per monitoring domain array of struct mbm_cntr_cfg that is indexed by the hardware
counter ID. A hardware counter's configuration contains the MBM event
ID and points to the monitoring group that it is assigned to, with a NULL pointer meaning that the hardware counter is available for assignment.
There is no direct way to determine which hardware counters are assigned
to a particular monitoring group. Check every entry of every hardware
counter configuration array in every monitoring domain to query which
MBM events of a monitoring group is tracked by hardware. Such queries are acceptable because <insert reason here>.
Please work on creating good changelogs. The requirements should be clear to you.
Reinette
Babu Moger
reviewerPATCH v10 13/24 x86/resctrl: Introduce interface to display number of free counters
In reply to Babu MogerProvide the interface to display the number of monitoring counters available for assignment in each domain when mbm_cntr_assign is supported.
---
v10: Patch changed to handle the counters at domain level.
https://lore.kernel.org/lkml/CALPaoCj+zWq1vkHVbXYP0znJbe6Ke3PXPWjtri5AFgD9cQDCUg@mail.gmail.com/
So, display logic also changed now.
v9: New patch
--- Documentation/arch/x86/resctrl.rst | 4 +++ arch/x86/kernel/cpu/resctrl/monitor.c | 1 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 47 ++++++++++++++++++++++++++ 3 files changed, 52 insertions(+)
Documentation/arch/x86/resctrl.rst +4 -0
@@ -302,6 +302,10 @@ with the following files: memory bandwidth tracking to a single memory bandwidth event per monitoring group. +"available_mbm_cntrs": + The number of monitoring counters available for assignment in each + domain when the architecture supports mbm_cntr_assign mode. + "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancy
arch/x86/kernel/cpu/resctrl/monitor.c +1 -0
@@ -1238,6 +1238,7 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r)cpuid_count (0x80000020 ,5 , &eax, &ebx, &ecx, &edx); r->mon.num_mbm_cntrs = (ebx &GENMASK (15 ,0 )) +1 ;resctrl_file_fflags_init ("num_mbm_cntrs" ,RFTYPE_MON_INFO ); +resctrl_file_fflags_init ("available_mbm_cntrs" ,RFTYPE_MON_INFO ); } }
arch/x86/kernel/cpu/resctrl/rdtgroup.c +47 -0
59 lines not on this page · raw message
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 13/24] x86/resctrl: Introduce interface to display number of free counters
([email protected] -> [email protected] to stop sending undeliverable emails)
Hi Babu,
Quoted 21 lines · Babu Moger
Provide the interface to display the number of monitoring counters available for assignment in each domain when
mbm_cntr_assignis supported.Signed-off-by Babu Moger <[email protected]>---
v10: Patch changed to handle the counters at domain level.
https://lore.kernel.org/lkml/CALPaoCj+zWq1vkHVbXYP0znJbe6Ke3PXPWjtri5AFgD9cQDCUg@mail.gmail.com/
So, display logic also changed now.v9: New patch
--- Documentation/arch/x86/resctrl.rst | 4 +++ arch/x86/kernel/cpu/resctrl/monitor.c | 1 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 47 ++++++++++++++++++++++++++ 3 files changed, 52 insertions(+)Documentation/arch/x86/resctrl.rst +0
-0
Documentation/arch/x86/resctrl.rst with the following files: · line 307
Quoted 6 lines
Documentation/arch/x86/resctrl.rst +3
-0@@ -302,6 +302,10 @@ with the following files: memory bandwidth tracking to a single memory bandwidth event per monitoring group. +"available_mbm_cntrs": + The number of monitoring counters available for assignment in each + domain when the architecture supports mbm_cntr_assign mode.
"architecture supports" -> "system supports"
It looks to me as though more than just support is required, the mode is also required to be enabled?
Quoted 21 lines
Documentation/arch/x86/resctrl.rst +1
-0+ "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancyarch/x86/kernel/cpu/resctrl/monitor.c +1
-0@@ -1238,6 +1238,7 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r)cpuid_count (0x80000020 ,5 , &eax, &ebx, &ecx, &edx); r->mon.num_mbm_cntrs = (ebx &GENMASK (15 ,0 )) +1 ;resctrl_file_fflags_init ("num_mbm_cntrs" ,RFTYPE_MON_INFO ); +resctrl_file_fflags_init ("available_mbm_cntrs" ,RFTYPE_MON_INFO ); } }arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_num_mbm_cntrs_show(struct kernfs_open_file *of, · line 883
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0@@ -879,6 +879,47 @@ static int rdtgroup_num_mbm_cntrs_show(struct kernfs_open_file *of,return 0 ; } +static int rdtgroup_available_mbm_cntrs_show (struct kernfs_open_file *of, +struct seq_file *s,void *v)
rdtgroup_
Quoted 7 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +7
-0+{ +struct rdt_resource *r = of->kn->parent->priv; +struct rdt_mon_domain *dom; +bool sep = false; +u32 cntrs, i; +int ret =0 ; +
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_num_mbm_cntrs_show(struct kernfs_open_file *of, · line 900
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+cpus_read_lock (); +mutex_lock (&rdtgroup_mutex); + +if (!resctrl_arch_mbm_cntr_assign_enabled (r)) { +rdt_last_cmd_puts ("mbm_cntr_assign mode is not enabled\n" ); + ret = -EINVAL ; + goto unlock_cntrs_show; + } + +
unnecessary empty line
Quoted 28 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +22
-0+list_for_each_entry (dom, &r->mon_domains, hdr.list) { +if (sep) +seq_puts (s,";" ); + + cntrs =0 ; +for (i =0 ; i < r->mon.num_mbm_cntrs; i++) { +if (!dom->cntr_cfg[i].rdtgrp) + cntrs++; + } + +seq_printf (s,"%d=%d" , dom->hdr.id, cntrs); + sep = true; + } +seq_puts (s,"\n" ); + +unlock_cntrs_show: +mutex_unlock (&rdtgroup_mutex); +cpus_read_unlock (); + +return ret; +} +#ifdef CONFIG_PROC_CPU_RESCTRL /* @@ -1961,6 +2002,12 @@ static struct rftype res_common_files[] = { .kf_ops = &rdtgroup_kf_single_ops, .seq_show = rdtgroup_num_mbm_cntrs_show,
arch/x86/kernel/cpu/resctrl/rdtgroup.c static struct rftype res_common_files[] = { · line 2013
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-0}, + { + .name = "available_mbm_cntrs", + .mode = 0444, + .kf_ops = &rdtgroup_kf_single_ops, + .seq_show = rdtgroup_available_mbm_cntrs_show, + }, { .name = "cpus_list", .mode = 0644,
Reinette
Re: [PATCH v10 13/24] x86/resctrl: Introduce interface to display number of free counters
Hi Reinette,
Quoted 1 line · Reinette Chatre
([email protected] -> [email protected] to stop sending undeliverable emails)
Yes. I know. My mistake when I grabbed the get_maintaners list.
Quoted 28 lines
Hi Babu,
Quoted 24 lines · Babu Moger
Provide the interface to display the number of monitoring counters available for assignment in each domain when
mbm_cntr_assignis supported.Signed-off-by Babu Moger <[email protected]>---
v10: Patch changed to handle the counters at domain level.
https://lore.kernel.org/lkml/CALPaoCj+zWq1vkHVbXYP0znJbe6Ke3PXPWjtri5AFgD9cQDCUg@mail.gmail.com/
So, display logic also changed now.v9: New patch
--- Documentation/arch/x86/resctrl.rst | 4 +++ arch/x86/kernel/cpu/resctrl/monitor.c | 1 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 47 ++++++++++++++++++++++++++ 3 files changed, 52 insertions(+)Documentation/arch/x86/resctrl.rst +0
-0@@ -302,6 +302,10 @@ with the following files: memory bandwidth tracking to a single memory bandwidth event per monitoring group.
Quoted 8 lines
Documentation/arch/x86/resctrl.rst with the following files: · line 307
Quoted 3 lines
Documentation/arch/x86/resctrl.rst +3
-0+"available_mbm_cntrs": + The number of monitoring counters available for assignment in each + domain when the architecture supports mbm_cntr_assign mode."architecture supports" -> "system supports"
It looks to me as though more than just support is required, the mode is also required to be enabled?
sure.
Quoted 25 lines
Quoted 25 lines
Documentation/arch/x86/resctrl.rst +1
-0+ "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancyarch/x86/kernel/cpu/resctrl/monitor.c +1
-0@@ -1238,6 +1238,7 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r)cpuid_count (0x80000020 ,5 , &eax, &ebx, &ecx, &edx); r->mon.num_mbm_cntrs = (ebx &GENMASK (15 ,0 )) +1 ;resctrl_file_fflags_init ("num_mbm_cntrs" ,RFTYPE_MON_INFO ); +resctrl_file_fflags_init ("available_mbm_cntrs" ,RFTYPE_MON_INFO ); } }arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -879,6 +879,47 @@ static int rdtgroup_num_mbm_cntrs_show(struct kernfs_open_file *of,return 0 ; }
Quoted 4 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_num_mbm_cntrs_show(struct kernfs_open_file *of, · line 883
Quoted 2 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0+static int rdtgroup_available_mbm_cntrs_show (struct kernfs_open_file *of, +struct seq_file *s,void *v)
rdtgroup_
Will change it to resctrl_
Quoted 12 lines
Quoted 12 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +11
-0+{ +struct rdt_resource *r = of->kn->parent->priv; +struct rdt_mon_domain *dom; +bool sep = false; +u32 cntrs, i; +int ret =0 ; + +cpus_read_lock (); +mutex_lock (&rdtgroup_mutex); + +if (!resctrl_arch_mbm_cntr_assign_enabled (r)) {
Quoted 9 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_num_mbm_cntrs_show(struct kernfs_open_file *of, · line 900
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-0+rdt_last_cmd_puts ("mbm_cntr_assign mode is not enabled\n" ); + ret = -EINVAL ; + goto unlock_cntrs_show; + } + +unnecessary empty line
ok.
thanks
Babu
Quoted 42 lines
Quoted 28 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +22
-0+list_for_each_entry (dom, &r->mon_domains, hdr.list) { +if (sep) +seq_puts (s,";" ); + + cntrs =0 ; +for (i =0 ; i < r->mon.num_mbm_cntrs; i++) { +if (!dom->cntr_cfg[i].rdtgrp) + cntrs++; + } + +seq_printf (s,"%d=%d" , dom->hdr.id, cntrs); + sep = true; + } +seq_puts (s,"\n" ); + +unlock_cntrs_show: +mutex_unlock (&rdtgroup_mutex); +cpus_read_unlock (); + +return ret; +} +#ifdef CONFIG_PROC_CPU_RESCTRL /* @@ -1961,6 +2002,12 @@ static struct rftype res_common_files[] = { .kf_ops = &rdtgroup_kf_single_ops, .seq_show = rdtgroup_num_mbm_cntrs_show,arch/x86/kernel/cpu/resctrl/rdtgroup.c static struct rftype res_common_files[] = { · line 2013
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-0}, + { + .name = "available_mbm_cntrs", + .mode = 0444, + .kf_ops = &rdtgroup_kf_single_ops, + .seq_show = rdtgroup_available_mbm_cntrs_show, + }, { .name = "cpus_list", .mode = 0644,Reinette
Re: [PATCH v10 13/24] x86/resctrl: Introduce interface to display number of free counters
In reply to Reinette ChatreHi Reinette,
Quoted 29 lines · Reinette Chatre
([email protected] -> [email protected] to stop sending undeliverable emails)
Hi Babu,
Quoted 24 lines · Babu Moger
Provide the interface to display the number of monitoring counters available for assignment in each domain when
mbm_cntr_assignis supported.Signed-off-by Babu Moger <[email protected]>---
v10: Patch changed to handle the counters at domain level.
https://lore.kernel.org/lkml/CALPaoCj+zWq1vkHVbXYP0znJbe6Ke3PXPWjtri5AFgD9cQDCUg@mail.gmail.com/
So, display logic also changed now.v9: New patch
--- Documentation/arch/x86/resctrl.rst | 4 +++ arch/x86/kernel/cpu/resctrl/monitor.c | 1 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 47 ++++++++++++++++++++++++++ 3 files changed, 52 insertions(+)Documentation/arch/x86/resctrl.rst +0
-0@@ -302,6 +302,10 @@ with the following files: memory bandwidth tracking to a single memory bandwidth event per monitoring group.
Quoted 8 lines
Documentation/arch/x86/resctrl.rst with the following files: · line 307
Quoted 3 lines
Documentation/arch/x86/resctrl.rst +3
-0+"available_mbm_cntrs": + The number of monitoring counters available for assignment in each + domain when the architecture supports mbm_cntr_assign mode."architecture supports" -> "system supports"
It looks to me as though more than just support is required, the mode is also required to be enabled?
Yes. It needs to be enabled.
The number of monitoring counters available for assignment in each domain when mbm_cntr_assign mode is enabled on the system.
Quoted 92 lines
Quoted 22 lines
Documentation/arch/x86/resctrl.rst +1
-0+ "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancyarch/x86/kernel/cpu/resctrl/monitor.c +1
-0@@ -1238,6 +1238,7 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r)cpuid_count (0x80000020 ,5 , &eax, &ebx, &ecx, &edx); r->mon.num_mbm_cntrs = (ebx &GENMASK (15 ,0 )) +1 ;resctrl_file_fflags_init ("num_mbm_cntrs" ,RFTYPE_MON_INFO ); +resctrl_file_fflags_init ("available_mbm_cntrs" ,RFTYPE_MON_INFO ); } }arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_num_mbm_cntrs_show(struct kernfs_open_file *of, · line 883
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0@@ -879,6 +879,47 @@ static int rdtgroup_num_mbm_cntrs_show(struct kernfs_open_file *of,return 0 ; } +static int rdtgroup_available_mbm_cntrs_show (struct kernfs_open_file *of, +struct seq_file *s,void *v)
rdtgroup_Quoted 7 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +7
-0+{ +struct rdt_resource *r = of->kn->parent->priv; +struct rdt_mon_domain *dom; +bool sep = false; +u32 cntrs, i; +int ret =0 ; +arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_num_mbm_cntrs_show(struct kernfs_open_file *of, · line 900
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+cpus_read_lock (); +mutex_lock (&rdtgroup_mutex); + +if (!resctrl_arch_mbm_cntr_assign_enabled (r)) { +rdt_last_cmd_puts ("mbm_cntr_assign mode is not enabled\n" ); + ret = -EINVAL ; + goto unlock_cntrs_show; + } + +unnecessary empty line
Quoted 28 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +22
-0+list_for_each_entry (dom, &r->mon_domains, hdr.list) { +if (sep) +seq_puts (s,";" ); + + cntrs =0 ; +for (i =0 ; i < r->mon.num_mbm_cntrs; i++) { +if (!dom->cntr_cfg[i].rdtgrp) + cntrs++; + } + +seq_printf (s,"%d=%d" , dom->hdr.id, cntrs); + sep = true; + } +seq_puts (s,"\n" ); + +unlock_cntrs_show: +mutex_unlock (&rdtgroup_mutex); +cpus_read_unlock (); + +return ret; +} +#ifdef CONFIG_PROC_CPU_RESCTRL /* @@ -1961,6 +2002,12 @@ static struct rftype res_common_files[] = { .kf_ops = &rdtgroup_kf_single_ops, .seq_show = rdtgroup_num_mbm_cntrs_show,arch/x86/kernel/cpu/resctrl/rdtgroup.c static struct rftype res_common_files[] = { · line 2013
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-0}, + { + .name = "available_mbm_cntrs", + .mode = 0444, + .kf_ops = &rdtgroup_kf_single_ops, + .seq_show = rdtgroup_available_mbm_cntrs_show, + }, { .name = "cpus_list", .mode = 0644,Reinette
Babu Moger
reviewerPATCH v10 14/24 x86/resctrl: Add data structures and definitions for ABMC assignment
In reply to Babu MogerThe ABMC feature provides an option to the user to assign a hardware counter to an RMID, event pair and monitor the bandwidth as long as the counter is assigned. The bandwidth events will be tracked by the hardware until the user changes the configuration. Each resctrl group can configure maximum two counters, one for total event and one for local event.
The ABMC feature implements an MSR L3_QOS_ABMC_CFG (C000_03FDh). Configuration is done by setting the counter id, bandwidth source (RMID) and bandwidth configuration supported by BMEC (Bandwidth Monitoring Event Configuration).
Attempts to read or write the MSR when ABMC is not enabled will result in a #GP(0) exception.
Introduce the data structures and definitions for MSR L3_QOS_ABMC_CFG (0xC000_03FDh):
=========================================================================
Bits Mnemonic Description Access Reset
Type Value
=========================================================================
63 CfgEn Configuration Enable R/W 0
62 CtrEn Enable/disable counting R/W 0
61:53 – Reserved MBZ 0
52:48 CtrID Counter Identifier R/W 0
47 IsCOS BwSrc field is a CLOSID R/W 0
(not an RMID)
46:44 – Reserved MBZ 0
43:32 BwSrc Bandwidth Source R/W 0
(RMID or CLOSID)
31:0 BwType Bandwidth configuration R/W 0
to track for this counter
==========================================================================
The feature details are documented in the APM listed below [1].
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3.3 Assignable Bandwidth Monitoring (ABMC).
---
v10: No changes.
v9: Removed the references of L3_QOS_ABMC_DSC.
Text changes about configuration in kernel doc.
v8: Update the configuration notes in kernel_doc.
Few commit message update.
v7: Removed the reference of L3_QOS_ABMC_DSC as it is not used anymore.
Moved the configuration notes to kernel_doc.
Adjusted the tabs for l3_qos_abmc_cfg and checkpatch seems happy.
v6: Removed all the fs related changes.
Added note on CfgEn,CtrEn.
Removed the definitions which are not used.
Removed cntr_id initialization.
v5: Moved assignment flags here (path 10/19 of v4).
Added MON_CNTR_UNSET definition to initialize cntr_id's. More details in commit log.
Renamed few fields in l3_qos_abmc_cfg for readability.
v4: Added more descriptions.
Changed the name abmc_ctr_id to ctr_id.
Added L3_QOS_ABMC_DSC. Used for reading the configuration.
v3: No changes.
v2: No changes.
--- arch/x86/include/asm/msr-index.h | 1 + arch/x86/kernel/cpu/resctrl/internal.h | 35 ++++++++++++++++++++++++++ 2 files changed, 36 insertions(+)
arch/x86/include/asm/msr-index.h +1 -0
@@ -1194,6 +1194,7 @@/* - AMD: */ #define MSR_IA32_MBA_BW_BASE 0xc0000200#define MSR_IA32_SMBA_BW_BASE 0xc0000280 +#define MSR_IA32_L3_QOS_ABMC_CFG 0xc00003fd#define MSR_IA32_L3_QOS_EXT_CFG 0xc00003ff#define MSR_IA32_EVT_CFG_BASE 0xc0000400
arch/x86/kernel/cpu/resctrl/internal.h +35 -0
@@ -602,6 +602,41 @@ union cpuid_0x10_x_edx {unsigned int full; }; +/* +* ABMC counters are configured by writing to L3_QOS_ABMC_CFG. +* @bw_type : Bandwidth configuration (supported by BMEC) +* tracked by the @cntr_id. +* @bw_src : Bandwidth source (RMID or CLOSID). +* @reserved1 : Reserved. +* @is_clos : @bw_src field is a CLOSID (not an RMID). +* @cntr_id : Counter identifier. +* @reserved : Reserved. +* @cntr_en : Counting enable bit. +* @cfg_en : Configuration enable bit. +* +* Configuration and counting: +* Counter can be configured across multiple writes to MSR. Configuration +* is applied only when @cfg_en = 1. Counter @cntr_id is reset when the +* configuration is applied. +* @cfg_en = 1, @cntr_en = 0 : Apply @cntr_id configuration but do not +* count events. +* @cfg_en = 1, @cntr_en = 1 : Apply @cntr_id configuration and start +* counting events. +*/ +union l3_qos_abmc_cfg { +struct { +unsigned long bw_type :32 , + bw_src :12 , + reserved1:3 , + is_clos :1 , + cntr_id :5 , + reserved :9 , + cntr_en :1 , + cfg_en :1 ; + } split; +unsigned long full; +}; +void rdt_last_cmd_clear (void );void rdt_last_cmd_puts (const char *s);__printf (1 ,2 )
Signature · 1 line
2.34.1
Babu Moger
reviewerPATCH v10 15/24 x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC
In reply to Babu MogerThe ABMC feature provides an option to the user to assign a hardware counter to an RMID, event pair and monitor the bandwidth as long as it is assigned. The assigned RMID will be tracked by the hardware until the user unassigns it manually.
Configure the counters by writing to the L3_QOS_ABMC_CFG MSR and specifying the counter ID, bandwidth source (RMID), and bandwidth event configuration.
Provide the interface to assign the counter ids to RMID.
The feature details are documented in the APM listed below [1].
[1] AMD64 Architecture Programmer's Manual Volume 2: System Programming
Publication # 24593 Revision 3.41 section 19.3.3.3 Assignable Bandwidth
Monitoring (ABMC).---
v10: Added call resctrl_arch_reset_rmid() to reset the RMID in the domain
inside IPI call.
SMP and non-SMP call support is not required in resctrl_arch_config_cntr with new domain specific assign approach/data structure. Commit message update.
v9: Removed the code to reset the architectural state. It will done
in another patch.
v8: Rename resctrl_arch_assign_cntr to resctrl_arch_config_cntr.
v7: Separated arch and fs functions. This patch only has arch implementation.
Added struct rdt_resource to the interface resctrl_arch_assign_cntr. Rename rdtgroup_abmc_cfg() to resctrl_abmc_config_one_amd().
v6: Removed mbm_cntr_alloc() from this patch to keep fs and arch code
separate.
Added code to update the counter assignment at domain level.
v5: Few name changes to match cntr_id.
Changed the function names to
rdtgroup_assign_cntr
resctr_arch_assign_cntr
More comments on commit log.
Added function summary.
v4: Commit message update.
User bitmap APIs where applicable. Changed the interfaces considering MPAM(arm). Added domain specific assignment.
v3: Removed the static from the prototype of rdtgroup_assign_abmc.
The function is not called directly from user anymore. These changes are related to global assignment interface.
v2: Minor text changes in commit message.
--- arch/x86/kernel/cpu/resctrl/internal.h | 3 ++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 58 ++++++++++++++++++++++++++ 2 files changed, 61 insertions(+)
arch/x86/kernel/cpu/resctrl/internal.h +3 -0
@@ -701,5 +701,8 @@ bool closid_allocated(unsigned int closid);int resctrl_find_cleanest_closid (void );void arch_mbm_evt_config_init (struct rdt_hw_mon_domain *hw_dom);unsigned int mon_event_config_index_get (u32 evtid); +int resctrl_arch_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d, +enum resctrl_event_id evtid,u32 rmid,u32 closid, +u32 cntr_id,bool assign);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */
arch/x86/kernel/cpu/resctrl/rdtgroup.c +58 -0
70 lines not on this page · raw message
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 15/24] x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC
([email protected] -> [email protected] to stop sending undeliverable emails)
Hi Babu,
Quoted 9 lines · Babu Moger
The ABMC feature provides an option to the user to assign a hardware counter to an RMID, event pair and monitor the bandwidth as long as it is assigned. The assigned RMID will be tracked by the hardware until the user unassigns it manually.
Configure the counters by writing to the
L3_QOS_ABMC_CFGMSR and specifying the counter ID, bandwidth source (RMID), and bandwidth event configuration.Provide the interface to assign the counter ids to RMID.
Until now in this series many patches "introduced interface X" and every time it was some new resctrl file that user space interacts with. This changelog starts with a context about "user to assign a hardware counter" and ends with "Provide the interface", but there is no new user interface in this patch. Can this be more specific about what this patch does?
Quoted 9 lines
The feature details are documented in the APM listed below [1].
[1] AMD64 Architecture Programmer's Manual Volume 2: System ProgrammingPublication # 24593 Revision 3.41 section 19.3.3.3 Assignable Bandwidth Monitoring (ABMC).---
....
Quoted 26 lines
--- arch/x86/kernel/cpu/resctrl/internal.h | 3 ++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 58 ++++++++++++++++++++++++++ 2 files changed, 61 insertions(+)arch/x86/kernel/cpu/resctrl/internal.h +3
-0@@ -701,5 +701,8 @@ bool closid_allocated(unsigned int closid);int resctrl_find_cleanest_closid (void );void arch_mbm_evt_config_init (struct rdt_hw_mon_domain *hw_dom);unsigned int mon_event_config_index_get (u32 evtid); +int resctrl_arch_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d, +enum resctrl_event_id evtid,u32 rmid,u32 closid, +u32 cntr_id,bool assign);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */ arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -1686,6 +1686,34 @@ unsigned int mon_event_config_index_get(u32 evtid) } }
arch/x86/kernel/cpu/resctrl/rdtgroup.c unsigned int mon_event_config_index_get(u32 evtid) · line 1698
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+struct cntr_config { +struct rdt_resource *r; +struct rdt_mon_domain *d; +enum resctrl_event_id evtid; +u32 rmid; +u32 closid; +u32 cntr_id; +u32 val; +bool assign; +};
I think I am missing something because it is not clear to me why this new struct is needed. Why not just use union l3_qos_abmc_cfg?
If it is indeed needed it needs better formatting and clear descriptions, a member like "val" is very generic.
arch/x86/kernel/cpu/resctrl/rdtgroup.c unsigned int mon_event_config_index_get(u32 evtid) · line 1704
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-0+ +static void resctrl_abmc_config_one_amd (void *info) +{ +struct cntr_config *config = info; +union l3_qos_abmc_cfg abmc_cfg = {0 }; +
reverse fir
Quoted 18 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +12
-0+ abmc_cfg.split.cfg_en =1 ; + abmc_cfg.split.cntr_en = config->assign ?1 :0 ; + abmc_cfg.split.cntr_id = config->cntr_id; + abmc_cfg.split.bw_src = config->rmid; + abmc_cfg.split.bw_type = config->val; + +wrmsrl (MSR_IA32_L3_QOS_ABMC_CFG , abmc_cfg.full); + +resctrl_arch_reset_rmid (config->r, config->d, config->closid, + config->rmid, config->evtid); +} +static int mbm_config_show (struct seq_file *s,struct rdt_resource *r,u32 evtid) {struct rdt_mon_domain *dom;@@ -1869,6 +1897,36 @@ static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of,return ret ?: nbytes; }
arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, · line 1908
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +9
-0+/* +* Send an IPI to the domain to assign the counter to RMID, event pair. +*/ +int resctrl_arch_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d, +enum resctrl_event_id evtid,u32 rmid,u32 closid, +u32 cntr_id,bool assign) +{ +struct rdt_hw_mon_domain *hw_dom =resctrl_to_arch_mon_dom (d); +struct cntr_config config = {0 };
Please see 29eaa7958367 ("x86/resctrl: Slightly clean-up mbm_config_show()")
Quoted 14 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +14
-0+ + config.r = r; + config.d = d; + config.evtid = evtid; + config.rmid = rmid; + config.closid = closid; + config.cntr_id = cntr_id; + +/* Update the event configuration from the domain */ +if (evtid ==QOS_L3_MBM_TOTAL_EVENT_ID ) + config.val = hw_dom->mbm_total_cfg; +else + config.val = hw_dom->mbm_local_cfg; +
arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, · line 1932
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +7
-0+ config.assign = assign; + +smp_call_function_any (&d->hdr.cpu_mask, resctrl_abmc_config_one_amd, &config,1 ); + +return 0 ; +} +/* rdtgroup information files for one cache resource. */ static struct rftype res_common_files[] = { {
Reinette
Re: [PATCH v10 15/24] x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC
Hi Reinette,
Quoted 1 line · Reinette Chatre
([email protected] -> [email protected] to stop sending undeliverable emails)
Yes.
Quoted 12 lines
Hi Babu,
Quoted 8 lines · Babu Moger
The ABMC feature provides an option to the user to assign a hardware counter to an RMID, event pair and monitor the bandwidth as long as it is assigned. The assigned RMID will be tracked by the hardware until the user unassigns it manually.
Configure the counters by writing to the
L3_QOS_ABMC_CFGMSR and specifying the counter ID, bandwidth source (RMID), and bandwidth event configuration.
Quoted 7 lines
Quoted 1 line
Provide the interface to assign the counter ids to RMID.
Until now in this series many patches "introduced interface X" and every time it was some new resctrl file that user space interacts with. This changelog starts with a context about "user to assign a hardware counter" and ends with "Provide the interface", but there is no new user interface in this patch. Can this be more specific about what this patch does?
Yes. This should be about resctrl_arch_config_cntr(). How about this?
The ABMC feature provides an option to the user to assign a hardware
counter to an RMID, event pair and monitor the bandwidth as long as it is assigned. The assigned RMID will be tracked by the hardware until the user unassigns it manually.
Provide the architecture specific handler to to assign/unassign the counter. Counters are configured by writing to the L3_QOS_ABMC_CFG MSR and specifying the counter ID, bandwidth source (RMID), and bandwidth event configuration.
Quoted 39 lines
Quoted 10 lines
The feature details are documented in the APM listed below [1].
[1] AMD64 Architecture Programmer's Manual Volume 2: System ProgrammingPublication # 24593 Revision 3.41 section 19.3.3.3 Assignable Bandwidth Monitoring (ABMC).---
....
Quoted 26 lines
--- arch/x86/kernel/cpu/resctrl/internal.h | 3 ++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 58 ++++++++++++++++++++++++++ 2 files changed, 61 insertions(+)arch/x86/kernel/cpu/resctrl/internal.h +3
-0@@ -701,5 +701,8 @@ bool closid_allocated(unsigned int closid);int resctrl_find_cleanest_closid (void );void arch_mbm_evt_config_init (struct rdt_hw_mon_domain *hw_dom);unsigned int mon_event_config_index_get (u32 evtid); +int resctrl_arch_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d, +enum resctrl_event_id evtid,u32 rmid,u32 closid, +u32 cntr_id,bool assign);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */ arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -1686,6 +1686,34 @@ unsigned int mon_event_config_index_get(u32 evtid) } }
Quoted 13 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c unsigned int mon_event_config_index_get(u32 evtid) · line 1698
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+struct cntr_config { +struct rdt_resource *r; +struct rdt_mon_domain *d; +enum resctrl_event_id evtid; +u32 rmid; +u32 closid; +u32 cntr_id; +u32 val; +bool assign; +};I think I am missing something because it is not clear to me why this new struct is needed. Why not just use union
l3_qos_abmc_cfg?
New struct is needed because we need to call resctrl_arch_reset_rmid() inside IPI. It requires all these parameters.
void resctrl_arch_reset_rmid(struct rdt_resource *r, struct rdt_mon_domain *d, u32 closid, u32 rmid, enum resctrl_event_id eventid);
Quoted 3 lines
If it is indeed needed it needs better formatting and clear descriptions, a member like "val" is very generic.
Sure. Will change it.
Quoted 9 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c unsigned int mon_event_config_index_get(u32 evtid) · line 1704
Quoted 7 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-0+ +static void resctrl_abmc_config_one_amd (void *info) +{ +struct cntr_config *config = info; +union l3_qos_abmc_cfg abmc_cfg = {0 }; +reverse fir
Sure.
Quoted 20 lines
Quoted 20 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +12
-0+ abmc_cfg.split.cfg_en =1 ; + abmc_cfg.split.cntr_en = config->assign ?1 :0 ; + abmc_cfg.split.cntr_id = config->cntr_id; + abmc_cfg.split.bw_src = config->rmid; + abmc_cfg.split.bw_type = config->val; + +wrmsrl (MSR_IA32_L3_QOS_ABMC_CFG , abmc_cfg.full); + +resctrl_arch_reset_rmid (config->r, config->d, config->closid, + config->rmid, config->evtid); +} +static int mbm_config_show (struct seq_file *s,struct rdt_resource *r,u32 evtid) {struct rdt_mon_domain *dom;@@ -1869,6 +1897,36 @@ static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of,return ret ?: nbytes; }
Quoted 11 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, · line 1908
Quoted 9 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +9
-0+/* +* Send an IPI to the domain to assign the counter to RMID, event pair. +*/ +int resctrl_arch_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d, +enum resctrl_event_id evtid,u32 rmid,u32 closid, +u32 cntr_id,bool assign) +{ +struct rdt_hw_mon_domain *hw_dom =resctrl_to_arch_mon_dom (d); +struct cntr_config config = {0 };Please see
29eaa7958367("x86/resctrl: Slightly clean-upmbm_config_show()")
This may not apply here.
x86/resctrl: Slightly clean-up mbm_config_show()
"mon_info' is already zeroed in the list_for_each_entry() loop below. There is no need to explicitly initialize it here. It just wastes some space and cycles.
In our case we are not doing memset again.
Thanks
Babu
Quoted 28 lines
Quoted 15 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +14
-0+ + config.r = r; + config.d = d; + config.evtid = evtid; + config.rmid = rmid; + config.closid = closid; + config.cntr_id = cntr_id; + +/* Update the event configuration from the domain */ +if (evtid ==QOS_L3_MBM_TOTAL_EVENT_ID ) + config.val = hw_dom->mbm_total_cfg; +else + config.val = hw_dom->mbm_local_cfg; +arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, · line 1932
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +7
-0+ config.assign = assign; + +smp_call_function_any (&d->hdr.cpu_mask, resctrl_abmc_config_one_amd, &config,1 ); + +return 0 ; +} +/* rdtgroup information files for one cache resource. */ static struct rftype res_common_files[] = { {Reinette
Reinette Chatre
maintainerRe: [PATCH v10 15/24] x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC
Hi Babu,
Quoted 27 lines · Babu
Hi Reinette,
Quoted 1 line · Reinette Chatre
([email protected] -> [email protected] to stop sending undeliverable emails)
Yes.
Quoted 12 lines
Hi Babu,
Quoted 8 lines · Babu Moger
The ABMC feature provides an option to the user to assign a hardware counter to an RMID, event pair and monitor the bandwidth as long as it is assigned. The assigned RMID will be tracked by the hardware until the user unassigns it manually.
Configure the counters by writing to the
L3_QOS_ABMC_CFGMSR and specifying the counter ID, bandwidth source (RMID), and bandwidth event configuration.Quoted 7 lines
Quoted 1 line
Provide the interface to assign the counter ids to RMID.
Until now in this series many patches "introduced interface X" and every time it was some new resctrl file that user space interacts with. This changelog starts with a context about "user to assign a hardware counter" and ends with "Provide the interface", but there is no new user interface in this patch. Can this be more specific about what this patch does?
Quoted 6 lines
Yes. This should be about
resctrl_arch_config_cntr(). How about this?The ABMC feature provides an option to the user to assign a hardware
counter to an RMID, event pair and monitor the bandwidth as long as it is assigned. The assigned RMID will be tracked by the hardware until the user unassigns it manually.Provide the architecture specific handler to to assign/unassign the counter. Counters are configured by writing to the
L3_QOS_ABMC_CFGMSR and specifying the counter ID, bandwidth source (RMID), and bandwidth event configuration.
Again just one sentence appended. The "to to" demonstrates it is another example of something typed quickly to see if it sticks.
Quoted 17 lines
Quoted 8 lines
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +4
-0@@ -1686,6 +1686,34 @@ unsigned int mon_event_config_index_get(u32 evtid) } } +struct cntr_config { + struct rdt_resource *r; + struct rdt_mon_domain *d; + enum resctrl_event_id evtid; + u32 rmid;Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c unsigned int mon_event_config_index_get(u32 evtid) · line 1698
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +5
-0+ u32 closid; + u32 cntr_id; + u32 val; + bool assign; +};I think I am missing something because it is not clear to me why this new struct is needed. Why not just use union
l3_qos_abmc_cfg?
Quoted 1 line
New struct is needed because we need to call
resctrl_arch_reset_rmid()inside IPI. It requires all these parameters.
Could you please answer my question?
Quoted 15 lines
Quoted 6 lines
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -1869,6 +1897,36 @@ static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, return ret ?: nbytes; }+/*
+ * Send an IPI to the domain to assign the counter to RMID, event pair.
+ */Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, · line 1908
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-0+int resctrl_arch_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d, + enum resctrl_event_id evtid, u32 rmid, u32 closid, + u32 cntr_id, bool assign) +{ + struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d); + struct cntr_config config = { 0 };Please see
29eaa7958367("x86/resctrl: Slightly clean-upmbm_config_show()")
Quoted 7 lines
This may not apply here.
x86/resctrl: Slightly clean-up
mbm_config_show()"
mon_info' is already zeroed in thelist_for_each_entry()loop below. There is no need to explicitly initialize it here. It just wastes some space and cycles.In our case we are not doing memset again.
No, but every member is explicitly initialized instead. It may be needed if union l3_qos_abmc_cfg is used as I asked about earlier where it will be important to ensure reserve bits are initialized.
Reinette
Re: [PATCH v10 15/24] x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC
Hi Reinette,
Quoted 32 lines · Reinette Chatre
Hi Babu,
Quoted 29 lines · Babu
Hi Reinette,
Quoted 1 line · Reinette Chatre
([email protected] -> [email protected] to stop sending undeliverable emails)
Yes.
Quoted 12 lines
Hi Babu,
Quoted 8 lines · Babu Moger
The ABMC feature provides an option to the user to assign a hardware counter to an RMID, event pair and monitor the bandwidth as long as it is assigned. The assigned RMID will be tracked by the hardware until the user unassigns it manually.
Configure the counters by writing to the
L3_QOS_ABMC_CFGMSR and specifying the counter ID, bandwidth source (RMID), and bandwidth event configuration.Quoted 7 lines
Quoted 1 line
Provide the interface to assign the counter ids to RMID.
Until now in this series many patches "introduced interface X" and every time it was some new resctrl file that user space interacts with. This changelog starts with a context about "user to assign a hardware counter" and ends with "Provide the interface", but there is no new user interface in this patch. Can this be more specific about what this patch does?
Yes. This should be about
resctrl_arch_config_cntr(). How about this?
Quoted 7 lines
Quoted 4 lines
The ABMC feature provides an option to the user to assign a hardware
counter to an RMID, event pair and monitor the bandwidth as long as it is assigned. The assigned RMID will be tracked by the hardware until the user unassigns it manually.Provide the architecture specific handler to to assign/unassign the counter. Counters are configured by writing to the
L3_QOS_ABMC_CFGMSR and specifying the counter ID, bandwidth source (RMID), and bandwidth event configuration.Again just one sentence appended. The "to to" demonstrates it is another example of something typed quickly to see if it sticks.
My bad. Will rewrite this.
Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -1686,6 +1686,34 @@ unsigned int mon_event_config_index_get(u32 evtid) } }arch/x86/kernel/cpu/resctrl/rdtgroup.c unsigned int mon_event_config_index_get(u32 evtid) · line 1697
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +9
-0+struct cntr_config { + struct rdt_resource *r; + struct rdt_mon_domain *d; + enum resctrl_event_id evtid; + u32 rmid; + u32 closid; + u32 cntr_id; + u32 val; + bool assign; +};I think I am missing something because it is not clear to me why this new struct is needed. Why not just use union
l3_qos_abmc_cfg?
Quoted 3 lines
Quoted 1 line
New struct is needed because we need to call
resctrl_arch_reset_rmid()inside IPI. It requires all these parameters.Could you please answer my question?
May be I did not understand your question here.
We need to do couple of things here in the IPI.
1. Configure the counter. This requires the cntr_id, rmid, event config value and assign(or unassign). This is to populate l3_qos_abmc_cfg and write the MSR.
2. Reset RMID. This requires rdt_resource, rdt_mon_domain, RMID, CLOSID and event.
So, I packed all these in a new structure and sent to IPI handler so that both these actions can be done in IPI.
Can this be simplified?
Quoted 20 lines
Quoted 20 lines
Quoted 15 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, · line 1907
Quoted 13 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +8
-0@@ -1869,6 +1897,36 @@ static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, return ret ?: nbytes; } +/* +* Send an IPI to the domain to assign the counter to RMID, event pair. +*/ +int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, + enum resctrl_event_id evtid, u32 rmid, u32 closid, + u32 cntr_id, bool assign) +{ + struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d); + struct cntr_config config = { 0 };Please see
29eaa7958367("x86/resctrl: Slightly clean-upmbm_config_show()")This may not apply here.
x86/resctrl: Slightly clean-up
mbm_config_show()
Quoted 7 lines
Quoted 3 lines
"
mon_info' is already zeroed in thelist_for_each_entry()loop below. There is no need to explicitly initialize it here. It just wastes some space and cycles.In our case we are not doing memset again.
No, but every member is explicitly initialized instead. It may be needed if union
l3_qos_abmc_cfgis used as I asked about earlier where it will be important to ensure reserve bits are initialized.
I missed your comment on reserve bits(Searched in this series). General rule is reserve bits should be written as zeros.
Thanks
Babu
Quoted 3 lines
Reinette
Reinette Chatre
maintainerRe: [PATCH v10 15/24] x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC
Hi Babu,
Quoted 29 lines · Babu
Quoted 20 lines · Reinette Chatre
Quoted 19 lines · Babu
Quoted 16 lines · Reinette Chatre
arch/x86/kernel/cpu/resctrl/rdtgroup.c unsigned int mon_event_config_index_get(u32 evtid) · line 1697
Quoted 13 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +9
-0@@ -1686,6 +1686,34 @@ unsigned int mon_event_config_index_get(u32 evtid) } } +struct cntr_config { + struct rdt_resource *r; + struct rdt_mon_domain *d; + enum resctrl_event_id evtid; + u32 rmid; + u32 closid; + u32 cntr_id; + u32 val; + bool assign; +};I think I am missing something because it is not clear to me why this new struct is needed. Why not just use union
l3_qos_abmc_cfg?Quoted 3 lines
Quoted 1 line
New struct is needed because we need to call
resctrl_arch_reset_rmid()inside IPI. It requires all these parameters.Could you please answer my question?
May be I did not understand your question here.
We need to do couple of things here in the IPI.
Quoted 7 lines
1. Configure the counter. This requires the
cntr_id, rmid, event config value and assign(or unassign). This is to populatel3_qos_abmc_cfgand write the MSR.2. Reset RMID. This requires
rdt_resource,rdt_mon_domain, RMID, CLOSID and event.So, I packed all these in a new structure and sent to IPI handler so that both these actions can be done in IPI.
Can this be simplified?
This is all architecture specific code so I think l3_qos_abmc_cfg can be initialized once and then passed around. Bouncing the individual members of l3_qos_abmc_cfg through struct cntr_config seems unnecessary to me. More specifically, would it not make things simpler to make l3_qos_abmc_cfg a member of cntr_config?
Quoted 21 lines
Quoted 21 lines
Quoted 21 lines
Quoted 6 lines
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -1869,6 +1897,36 @@ static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, return ret ?: nbytes; }+/*
+ * Send an IPI to the domain to assign the counter to RMID, event pair.
+ */Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, · line 1908
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-0+int resctrl_arch_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d, + enum resctrl_event_id evtid, u32 rmid, u32 closid, + u32 cntr_id, bool assign) +{ + struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d); + struct cntr_config config = { 0 };Please see
29eaa7958367("x86/resctrl: Slightly clean-upmbm_config_show()")This may not apply here.
x86/resctrl: Slightly clean-up
mbm_config_show()"
mon_info' is already zeroed in thelist_for_each_entry()loop below. There is no need to explicitly initialize it here. It just wastes some space and cycles.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
In our case we are not doing memset again.
No, but every member is explicitly initialized instead. It may be needed if union
l3_qos_abmc_cfgis used as I asked about earlier where it will be important to ensure reserve bits are initialized.I missed your comment on reserve bits(Searched in this series). General rule is reserve bits should be written as zeros.
I do not think I am being clear.
Back to original comment: resctrl_arch_config_cntr() zeroes the entire struct and then initializes every member. I do not think it is necessary to zero the struct if every member is initialized. If you want to be explicit about the zero initialization you can do so while initializing the struct only once where it is defined. See for example, rdtgroup_kn_set_ugid()
Reinette
Re: [PATCH v10 15/24] x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC
Hi Reinette,
Quoted 36 lines · Reinette Chatre
Hi Babu,
Quoted 33 lines · Babu
Quoted 20 lines · Reinette Chatre
Quoted 19 lines · Babu
Quoted 16 lines · Reinette Chatre
arch/x86/kernel/cpu/resctrl/rdtgroup.c unsigned int mon_event_config_index_get(u32 evtid) · line 1697
Quoted 13 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +9
-0@@ -1686,6 +1686,34 @@ unsigned int mon_event_config_index_get(u32 evtid) } } +struct cntr_config { + struct rdt_resource *r; + struct rdt_mon_domain *d; + enum resctrl_event_id evtid; + u32 rmid; + u32 closid; + u32 cntr_id; + u32 val; + bool assign; +};I think I am missing something because it is not clear to me why this new struct is needed. Why not just use union
l3_qos_abmc_cfg?Quoted 3 lines
Quoted 1 line
New struct is needed because we need to call
resctrl_arch_reset_rmid()inside IPI. It requires all these parameters.Could you please answer my question?
May be I did not understand your question here.
We need to do couple of things here in the IPI.
1. Configure the counter. This requires the
cntr_id, rmid, event config value and assign(or unassign). This is to populatel3_qos_abmc_cfgand write the MSR.2. Reset RMID. This requires
rdt_resource,rdt_mon_domain, RMID, CLOSID and event.
Quoted 8 lines
Quoted 3 lines
So, I packed all these in a new structure and sent to IPI handler so that both these actions can be done in IPI.
Can this be simplified?
This is all architecture specific code so I think
l3_qos_abmc_cfgcan be initialized once and then passed around. Bouncing the individual members ofl3_qos_abmc_cfgthrough structcntr_configseems unnecessary to me. More specifically, would it not make things simpler to makel3_qos_abmc_cfga member ofcntr_config?
Yes. It can be done.
Quoted 31 lines
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
Quoted 15 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, · line 1907
Quoted 13 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +8
-0@@ -1869,6 +1897,36 @@ static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of, return ret ?: nbytes; } +/* +* Send an IPI to the domain to assign the counter to RMID, event pair. +*/ +int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, + enum resctrl_event_id evtid, u32 rmid, u32 closid, + u32 cntr_id, bool assign) +{ + struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d); + struct cntr_config config = { 0 };Please see
29eaa7958367("x86/resctrl: Slightly clean-upmbm_config_show()")This may not apply here.
x86/resctrl: Slightly clean-up
mbm_config_show()"
mon_info' is already zeroed in thelist_for_each_entry()loop below. There is no need to explicitly initialize it here. It just wastes some space and cycles.Quoted 7 lines
Quoted 5 lines
Quoted 1 line
In our case we are not doing memset again.
No, but every member is explicitly initialized instead. It may be needed if union
l3_qos_abmc_cfgis used as I asked about earlier where it will be important to ensure reserve bits are initialized.I missed your comment on reserve bits(Searched in this series). General rule is reserve bits should be written as zeros.
Quoted 7 lines
I do not think I am being clear.
Back to original comment:
resctrl_arch_config_cntr()zeroes the entire struct and then initializes every member. I do not think it is necessary to zero the struct if every member is initialized. If you want to be explicit about the zero initialization you can do so while initializing the struct only once where it is defined. See for example,rdtgroup_kn_set_ugid()
Yes. I got it. It was not required as we are initializing all the members of config here.
With adding l3_qos_abmc_cfg inside cntr_config, we may still have to keep it.
Thanks
Babu
Babu Moger
reviewerPATCH v10 16/24 x86/resctrl: Add interface to the assign counter
In reply to Babu MogerThe mbm_cntr_assign mode offers several counters that can be assigned to an RMID, event pair and monitor the bandwidth as long as it is assigned.
Counters are managed at the domain level. Introduce the interface to allocate/free/assign the counters.
If the user requests assignments across all domains, some domains may fail if they run out of counters. Ensure assignments continue in other domains wherever possible.
---
v10: Patch changed completely.
Counters are managed at the domain based on the discussion.
https://lore.kernel.org/lkml/CALPaoCj+zWq1vkHVbXYP0znJbe6Ke3PXPWjtri5AFgD9cQDCUg@mail.gmail.com/
Reset non-architectural MBM state.
Commit message update.
v9: Introduced new function resctrl_config_cntr to assign the counter, update
the bitmap and reset the architectural state.
Taken care of error handling(freeing the counter) when assignment fails. Moved mbm_cntr_assigned_to_domain here as it used in this patch. Minor text changes.
v8: Renamed rdtgroup_assign_cntr() to rdtgroup_assign_cntr_event().
Added the code to return the error if rdtgroup_assign_cntr_event fails. Moved definition of MBM_EVENT_ARRAY_INDEX to resctrl/internal.h. Updated typo in the comments.
v7: New patch. Moved all the FS code here.
Merged rdtgroup_assign_cntr and rdtgroup_alloc_cntr. Adde new #define MBM_EVENT_ARRAY_INDEX.
--- arch/x86/kernel/cpu/resctrl/internal.h | 5 +- arch/x86/kernel/cpu/resctrl/monitor.c | 4 +- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 110 +++++++++++++++++++++++++ 3 files changed, 116 insertions(+), 3 deletions(-)
arch/x86/kernel/cpu/resctrl/internal.h +4 -1
@@ -704,5 +704,8 @@ unsigned int mon_event_config_index_get(u32 evtid);int resctrl_arch_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d,enum resctrl_event_id evtid,u32 rmid,u32 closid,u32 cntr_id,bool assign); - +int rdtgroup_assign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp, +struct rdt_mon_domain *d,enum resctrl_event_id evtid); +struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid, +u32 rmid,enum resctrl_event_id evtid);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */
arch/x86/kernel/cpu/resctrl/monitor.c +2 -2
@@ -575,8 +575,8 @@ void free_rmid(u32 closid, u32 rmid)list_add_tail (&entry->list, &rmid_free_lru); } -static struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid, -u32 rmid,enum resctrl_event_id evtid) +struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid, +u32 rmid,enum resctrl_event_id evtid) {u32 idx =resctrl_arch_rmid_idx_encode (closid, rmid);
arch/x86/kernel/cpu/resctrl/rdtgroup.c +110 -0
116 lines not on this page · raw message
Signature · 1 line
2.34.1
Luck, Tony
maintainerRe: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Quoted 8 lines · Babu Moger
arch/x86/kernel/cpu/resctrl/rdtgroup.c +8
-0+/* +* Assign a hardware counter to event @evtid of group @rdtgrp. +* Counter will be assigned to all the domains if rdt_mon_domain is NULL +* else the counter will be assigned to specific domain. +*/ +int rdtgroup_assign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp, +struct rdt_mon_domain *d,enum resctrl_event_id evtid) +{
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 2010
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+int cntr_id, ret =0 ; + +if (!d) { +list_for_each_entry (d, &r->mon_domains, hdr.list) { +if (mbm_cntr_assigned (r, d, rdtgrp, evtid)) +continue ; + + cntr_id =mbm_cntr_alloc (r, d, rdtgrp, evtid); +if (cntr_id <0 ) { +rdt_last_cmd_puts ("Domain Out of MBM assignable counters\n" );
Message could be more helpful by including the domain number.
Review
Quoted 1 line
(quoted diff) +1
-0+ continue;
Not sure whether continuing is the right thing to do here. Sure the other domains may have available counters, but now you may have a confused status where some requested operations succeeded and others failed.
Quoted 4 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +4
-0+ } + + ret =resctrl_config_cntr (r, d, evtid, rdtgrp->mon.rmid, + rdtgrp->closid, cntr_id, true);
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 2025
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+if (ret) + goto out_done_assign; + } + }else { +if (mbm_cntr_assigned (r, d, rdtgrp, evtid)) + goto out_done_assign; + + cntr_id =mbm_cntr_alloc (r, d, rdtgrp, evtid); +if (cntr_id <0 ) { +rdt_last_cmd_puts ("Domain Out of MBM assignable counters\n" );
Ditto helpful to include domain number.
Review
Quoted 1 line
(quoted diff) +1
-0+ goto out_done_assign;
When you run out of counters here, you still return 0 from this function. This means that updating via write to the "mbm_assign_control" file may return success, even though the operation failed.
E.g. with no counters available:
# cat available_mbm_cntrs 0=0;1=0
Try to set a monitor domain to record local bandwidth:
# echo 'c1/m94/0=l;1=_;' > mbm_assign_control # echo $? 0
Looks like it worked!
But it didn't.
# cat ../last_cmd_status Domain Out of MBM assignable counters
rdtgroup_assign_cntr_event() does say that it didn't if you think to check here.
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 2038
Quoted 12 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +12
-0+ } + + ret =resctrl_config_cntr (r, d, evtid, rdtgrp->mon.rmid, + rdtgrp->closid, cntr_id, true); + } + +out_done_assign: +if (ret) +mbm_cntr_free (r, d, rdtgrp, evtid); + +return ret; +}
-Tony
Re: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Hi Tony,
Quoted 13 lines · Tony
Quoted 12 lines · Babu Moger
arch/x86/kernel/cpu/resctrl/rdtgroup.c +12
-0+/* +* Assign a hardware counter to event @evtid of group @rdtgrp. +* Counter will be assigned to all the domains if rdt_mon_domain is NULL +* else the counter will be assigned to specific domain. +*/ +int rdtgroup_assign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp, +struct rdt_mon_domain *d,enum resctrl_event_id evtid) +{ +int cntr_id, ret =0 ; + +if (!d) { +list_for_each_entry (d, &r->mon_domains, hdr.list) {
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 2010
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-0+if (mbm_cntr_assigned (r, d, rdtgrp, evtid)) +continue ; + + cntr_id =mbm_cntr_alloc (r, d, rdtgrp, evtid); +if (cntr_id <0 ) { +rdt_last_cmd_puts ("Domain Out of MBM assignable counters\n" );Message could be more helpful by including the domain number.
Yes. We can do that. I will to use rdt_last_cmd_printf().
Quoted 8 lines
Review
Quoted 2 lines
(quoted diff) +1
-0+ continue;Not sure whether continuing is the right thing to do here. Sure the other domains may have available counters, but now you may have a confused status where some requested operations succeeded and others failed.
Quoted 16 lines
Quoted 4 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +4
-0+ } + + ret =resctrl_config_cntr (r, d, evtid, rdtgrp->mon.rmid, + rdtgrp->closid, cntr_id, true);arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 2025
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+if (ret) + goto out_done_assign; + } + }else { +if (mbm_cntr_assigned (r, d, rdtgrp, evtid)) + goto out_done_assign; + + cntr_id =mbm_cntr_alloc (r, d, rdtgrp, evtid); +if (cntr_id <0 ) { +rdt_last_cmd_puts ("Domain Out of MBM assignable counters\n" );Ditto helpful to include domain number.
Sure.
Quoted 20 lines
Review
Quoted 2 lines
(quoted diff) +1
-0+ goto out_done_assign;When you run out of counters here, you still return 0 from this function. This means that updating via write to the "
mbm_assign_control" file may return success, even though the operation failed.E.g. with no counters available:
# cat available_mbm_cntrs 0=0;1=0Try to set a monitor domain to record local bandwidth:
# echo 'c1/m94/0=l;1=_;' > mbm_assign_control # echo $? 0Looks like it worked!
Quoted 7 lines
But it didn't.
# cat ../last_cmd_status Domain Out of MBM assignable counters
rdtgroup_assign_cntr_event()does say that it didn't if you think to check here.
Yes. Agree.
It is right thing to continue assignment if one of the domain is out of counters. In that case how about we save the error(say error_domain) and continue. And finally return success if both ret and error_domain are zeros.
return ret ? ret : error_domain:
Quoted 16 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 2038
Quoted 13 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +12
-0+ } + + ret =resctrl_config_cntr (r, d, evtid, rdtgrp->mon.rmid, + rdtgrp->closid, cntr_id, true); + } + +out_done_assign: +if (ret) +mbm_cntr_free (r, d, rdtgrp, evtid); + +return ret; +}-Tony
thanks
Babu
Luck, Tony
maintainerRE: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Quoted 5 lines
It is right thing to continue assignment if one of the domain is out of counters. In that case how about we save the
error(say error_domain)and continue. And finally return success if both ret anderror_domainare zeros.return ret ? ret :
error_domain:
If there are many domains, then you might have 3 succeed and 5 fail.
I think the best you can do is return success if everything succeeded and an error if any failed.
You have the same issue if someone tries to update multiple things with a single write to mbm_assign_control:
# cat > mbm_assign_control << EOF c1/m78/0=t;1=l; c1/m79/0=t;1=l c1/m80/0=t;1=l; c1/m81/0=t;1=l; EOF
Those get processed in order, some may succeed, but once a domain is out of counters the rest for that domain will fail.
Updates to schemata are handled in multiple passes to either have all succeed or all fail. But the only problems that can occur are user syntax/range issues. So it's a lot simpler.
For writes to mbm_assign_control I think it's okay to document that some requests may have been applied even though the whole request reports failure. The user can always read the file to check status.
-Tony
Re: RE: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Hi Tony,
Quoted 10 lines · Tony
Quoted 5 lines
It is right thing to continue assignment if one of the domain is out of counters. In that case how about we save the
error(say error_domain)and continue. And finally return success if both ret anderror_domainare zeros.return ret ? ret :
error_domain:If there are many domains, then you might have 3 succeed and 5 fail.
I think the best you can do is return success if everything succeeded and an error if any failed.
Yes. The above check should take care of this case.
Quoted 11 lines
You have the same issue if someone tries to update multiple things with a single write to
mbm_assign_control:# cat > mbm_assign_control << EOF c1/m78/0=t;1=l; c1/m79/0=t;1=l c1/m80/0=t;1=l; c1/m81/0=t;1=l; EOF
Quoted 2 lines
Those get processed in order, some may succeed, but once a domain is out of counters the rest for that domain will fail.
Yes. I see the similar type of processing for schemata. It is processed sequentially. If one fails, it returns immediately.
ret = rdtgroup_parse_resource(resname, tok, rdtgrp); if (ret)
goto out;
I feel it is ok to keep same level of processing.
Quoted 8 lines
Updates to schemata are handled in multiple passes to either have all succeed or all fail. But the only problems that can occur are user syntax/range issues. So it's a lot simpler.
For writes to
mbm_assign_controlI think it's okay to document that some requests may have been applied even though the whole request reports failure. The user can always read the file to check status.
Yes. We can document this.
Quoted 2 lines
-Tony
Reinette Chatre
maintainerRe: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Quoted 5 lines · Babu
Quoted 4 lines · Tony
Quoted 4 lines
It is right thing to continue assignment if one of the domain is out of counters. In that case how about we save the
error(say error_domain)and continue. And finally return success if both ret anderror_domainare zeros.
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
return ret ? ret :
error_domain:If there are many domains, then you might have 3 succeed and 5 fail.
I think the best you can do is return success if everything succeeded and an error if any failed.
Yes. The above check should take care of this case.
If I understand correctly "error_domain" can capture the ID of a single failing domain. If there are multiple failing domains like in Tony's example then "error_domain" will not be accurate and thus can never be trusted. Instead of a single check of a failure user space is then forced to parse the more complex "mbm_assign_control" file to learn what succeeded and failed.
Would it not be simpler to process sequentially and then fail on first error encountered with detailed error message? With that user space can determine exactly which portion of request succeeded and which portion failed.
Quoted 14 lines
Quoted 11 lines
You have the same issue if someone tries to update multiple things with a single write to
mbm_assign_control:# cat > mbm_assign_control << EOF c1/m78/0=t;1=l; c1/m79/0=t;1=l c1/m80/0=t;1=l; c1/m81/0=t;1=l; EOFQuoted 2 lines
Those get processed in order, some may succeed, but once a domain is out of counters the rest for that domain will fail.
Quoted 9 lines
Yes. I see the similar type of processing for schemata. It is processed sequentially. If one fails, it returns immediately.
ret =
rdtgroup_parse_resource(resname, tok, rdtgrp); if (ret)
goto out;I feel it is ok to keep same level of processing.
resctrl also does sequential processing when, for example, the user requests move of several tasks. resctrl returns with failure right away with error message containing failing PID. This gives clear information to user what portion of request succeeded without requiring user space to
do additional queries.
Reinette
Re: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Hi Reinette,
Quoted 25 lines · Reinette Chatre
Quoted 5 lines · Babu
Quoted 4 lines · Tony
Quoted 4 lines
It is right thing to continue assignment if one of the domain is out of counters. In that case how about we save the
error(say error_domain)and continue. And finally return success if both ret anderror_domainare zeros.Quoted 9 lines
Quoted 6 lines
Quoted 1 line
return ret ? ret :
error_domain:If there are many domains, then you might have 3 succeed and 5 fail.
I think the best you can do is return success if everything succeeded and an error if any failed.
Yes. The above check should take care of this case.
If I understand correctly "
error_domain" can capture the ID of a single failing domain. If there are multiple failing domains like in Tony's example then "error_domain" will not be accurate and thus can never be trusted. Instead of a single check of a failure user space is then forced to parse the more complex "mbm_assign_control" file to learn what succeeded and failed.
Quoted 4 lines
Would it not be simpler to process sequentially and then fail on first error encountered with detailed error message? With that user space can determine exactly which portion of request succeeded and which portion failed.
One more option is to print the error for each failure and continue. And finally return error.
"Group mon1, domain:1 Out of MBM counters"
We have the error information as well as the convenience of assignment on domains where counters are available when user is working with "*"(all domains).
Note: I will be out of office starting next week Until Jan 10.
Quoted 34 lines
Quoted 15 lines
Quoted 12 lines
You have the same issue if someone tries to update multiple things with a single write to
mbm_assign_control:# cat > mbm_assign_control << EOF c1/m78/0=t;1=l; c1/m79/0=t;1=l c1/m80/0=t;1=l; c1/m81/0=t;1=l; EOFQuoted 2 lines
Those get processed in order, some may succeed, but once a domain is out of counters the rest for that domain will fail.
Quoted 9 lines
Yes. I see the similar type of processing for schemata. It is processed sequentially. If one fails, it returns immediately.
ret =
rdtgroup_parse_resource(resname, tok, rdtgrp); if (ret)
goto out;I feel it is ok to keep same level of processing.
resctrl also does sequential processing when, for example, the user requests move of several tasks. resctrl returns with failure right away with error message containing failing PID. This gives clear information to user what portion of request succeeded without requiring user space to
do additional queries.Reinette
Reinette Chatre
maintainerRe: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Hi Babu,
Quoted 33 lines · Babu
Hi Reinette,
Quoted 25 lines · Reinette Chatre
Quoted 5 lines · Babu
Quoted 4 lines · Tony
Quoted 4 lines
It is right thing to continue assignment if one of the domain is out of counters. In that case how about we save the
error(say error_domain)and continue. And finally return success if both ret anderror_domainare zeros.Quoted 9 lines
Quoted 6 lines
Quoted 1 line
return ret ? ret :
error_domain:If there are many domains, then you might have 3 succeed and 5 fail.
I think the best you can do is return success if everything succeeded and an error if any failed.
Yes. The above check should take care of this case.
If I understand correctly "
error_domain" can capture the ID of a single failing domain. If there are multiple failing domains like in Tony's example then "error_domain" will not be accurate and thus can never be trusted. Instead of a single check of a failure user space is then forced to parse the more complex "mbm_assign_control" file to learn what succeeded and failed.Quoted 4 lines
Would it not be simpler to process sequentially and then fail on first error encountered with detailed error message? With that user space can determine exactly which portion of request succeeded and which portion failed.
Quoted 5 lines
One more option is to print the error for each failure and continue. And finally return error.
"Group mon1, domain:1 Out of MBM counters"
We have the error information as well as the convenience of assignment on domains where counters are available when user is working with "*"(all domains).
This may be possible. Please keep in mind that any errors have to be easily consumed in an automated way to support the user space tools that interact with resctrl. I do not think we have thus far focused on the "last_cmd_status" buffer as part of the user space ABI so this opens up more considerations.
At this time the error handling of "all domains" does not seem to be consistent and obvious to user space. From what I can tell the implementation continues on to the next domain if one domain is out of counters but it exits immediately if a counter cannot be configured on a particular domain.
Quoted 2 lines
Note: I will be out of office starting next week Until Jan 10.
Thank you for letting me know. I am currently reviewing this series and will post feedback by tomorrow.
Reinette
Re: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Hi Reinette,
Quoted 48 lines · Reinette Chatre
Hi Babu,
Quoted 33 lines · Babu
Hi Reinette,
Quoted 25 lines · Reinette Chatre
Quoted 5 lines · Babu
Quoted 4 lines · Tony
Quoted 4 lines
It is right thing to continue assignment if one of the domain is out of counters. In that case how about we save the
error(say error_domain)and continue. And finally return success if both ret anderror_domainare zeros.Quoted 9 lines
Quoted 6 lines
Quoted 1 line
return ret ? ret :
error_domain:If there are many domains, then you might have 3 succeed and 5 fail.
I think the best you can do is return success if everything succeeded and an error if any failed.
Yes. The above check should take care of this case.
If I understand correctly "
error_domain" can capture the ID of a single failing domain. If there are multiple failing domains like in Tony's example then "error_domain" will not be accurate and thus can never be trusted. Instead of a single check of a failure user space is then forced to parse the more complex "mbm_assign_control" file to learn what succeeded and failed.Quoted 4 lines
Would it not be simpler to process sequentially and then fail on first error encountered with detailed error message? With that user space can determine exactly which portion of request succeeded and which portion failed.
Quoted 5 lines
One more option is to print the error for each failure and continue. And finally return error.
"Group mon1, domain:1 Out of MBM counters"
We have the error information as well as the convenience of assignment on domains where counters are available when user is working with "*"(all domains).
This may be possible. Please keep in mind that any errors have to be easily consumed in an automated way to support the user space tools that interact with resctrl. I do not think we have thus far focused on the "
last_cmd_status" buffer as part of the user space ABI so this opens up more considerations.
Quoted 5 lines
At this time the error handling of "all domains" does not seem to be consistent and obvious to user space. From what I can tell the implementation continues on to the next domain if one domain is out of counters but it exits immediately if a counter cannot be configured on a particular domain.
Yes. We can handle both the errors in the same way.
Quoted 6 lines
Quoted 3 lines
Note: I will be out of office starting next week Until Jan 10.
Thank you for letting me know. I am currently reviewing this series and will post feedback by tomorrow.
Sure. Thanks. I will try to get to some of it at least. The review comments which needs investigation may have to wait. Lets see.
Thanks
Babu
Luck, Tony
maintainerRE: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Quoted 21 lines
Quoted 21 lines
Quoted 21 lines
Quoted 21 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
It is right thing to continue assignment if one of the domain is out of counters. In that case how about we save the
error(say error_domain)and continue. And finally return success if both ret anderror_domainare zeros.Quoted 9 lines
Quoted 6 lines
Quoted 1 line
return ret ? ret :
error_domain:If there are many domains, then you might have 3 succeed and 5 fail.
I think the best you can do is return success if everything succeeded and an error if any failed.
Yes. The above check should take care of this case.
If I understand correctly "
error_domain" can capture the ID of a single failing domain. If there are multiple failing domains like in Tony's example then "error_domain" will not be accurate and thus can never be trusted. Instead of a single check of a failure user space is then forced to parse the more complex "mbm_assign_control" file to learn what succeeded and failed.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
Would it not be simpler to process sequentially and then fail on first error encountered with detailed error message? With that user space can determine exactly which portion of request succeeded and which portion failed.
One more option is to print the error for each failure and continue. And finally return error.
There's limited space allocated for use by last_cmd_*() messages:
static char last_cmd_status_buf[512];
seq_buf_init(&last_cmd_status, last_cmd_status_buf,
sizeof(last_cmd_status_buf));If you keep parsing and trying to apply changes from user input you will quickly hit that limit.
Quoted 11 lines
Quoted 11 lines
Quoted 4 lines
"Group mon1, domain:1 Out of MBM counters"
We have the error information as well as the convenience of assignment on domains where counters are available when user is working with "*"(all domains).
This may be possible. Please keep in mind that any errors have to be easily consumed in an automated way to support the user space tools that interact with resctrl. I do not think we have thus far focused on the "
last_cmd_status" buffer as part of the user space ABI so this opens up more considerations.
Quoted 7 lines
Quoted 5 lines
At this time the error handling of "all domains" does not seem to be consistent and obvious to user space. From what I can tell the implementation continues on to the next domain if one domain is out of counters but it exits immediately if a counter cannot be configured on a particular domain.
Yes. We can handle both the errors in the same way.
I think it is simplest to make the "same way" be "fail on first error".
Quoted 10 lines
Quoted 7 lines
Quoted 4 lines
Note: I will be out of office starting next week Until Jan 10.
Thank you for letting me know. I am currently reviewing this series and will post feedback by tomorrow.
Sure. Thanks. I will try to get to some of it at least. The review comments which needs investigation may have to wait. Lets see.
-Tony
Re: RE: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Hi Tony,
Quoted 30 lines · Tony
Quoted 21 lines
Quoted 21 lines
Quoted 21 lines
Quoted 21 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
It is right thing to continue assignment if one of the domain is out of counters. In that case how about we save the
error(say error_domain)and continue. And finally return success if both ret anderror_domainare zeros.Quoted 9 lines
Quoted 6 lines
Quoted 1 line
return ret ? ret :
error_domain:If there are many domains, then you might have 3 succeed and 5 fail.
I think the best you can do is return success if everything succeeded and an error if any failed.
Yes. The above check should take care of this case.
If I understand correctly "
error_domain" can capture the ID of a single failing domain. If there are multiple failing domains like in Tony's example then "error_domain" will not be accurate and thus can never be trusted. Instead of a single check of a failure user space is then forced to parse the more complex "mbm_assign_control" file to learn what succeeded and failed.Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
Would it not be simpler to process sequentially and then fail on first error encountered with detailed error message? With that user space can determine exactly which portion of request succeeded and which portion failed.
One more option is to print the error for each failure and continue. And finally return error.
There's limited space allocated for use by last_cmd_*() messages:
Quoted 7 lines
static char last_cmd_status_buf[512];
seq_buf_init(&last_cmd_status, last_cmd_status_buf, sizeof(last_cmd_status_buf));If you keep parsing and trying to apply changes from user input you will quickly hit that limit.
oh. ok. Good to know.
Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 6 lines
"Group mon1, domain:1 Out of MBM counters"
We have the error information as well as the convenience of assignment on domains where counters are available when user is working with "*"(all domains).
This may be possible. Please keep in mind that any errors have to be easily consumed in an automated way to support the user space tools that interact with resctrl. I do not think we have thus far focused on the "
last_cmd_status" buffer as part of the user space ABI so this opens up more considerations.At this time the error handling of "all domains" does not seem to be consistent and obvious to user space. From what I can tell the implementation continues on to the next domain if one domain is out of counters but it exits immediately if a counter cannot be configured on a particular domain.
Quoted 3 lines
Quoted 1 line
Yes. We can handle both the errors in the same way.
I think it is simplest to make the "same way" be "fail on first error".
Ok. Sure. Will do thanks.
-Babu
Reinette Chatre
maintainerRe: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
In reply to Babu MogerHi Babu,
Quoted 6 lines · Babu Moger
The
mbm_cntr_assignmode offers several counters that can be assigned to an RMID, event pair and monitor the bandwidth as long as it is assigned.Counters are managed at the domain level. Introduce the interface to allocate/free/assign the counters.
Changelog of previous patch also claimed to "Provide the interface to assign the counter ids to RMID." Please let changelogs describe the change more accurately.
(This still does not provide a user interface so what is meant by interface is unclear)
arch/x86/kernel/cpu/resctrl/internal.h unsigned int mon_event_config_index_get(u32 evtid); · line 708
Quoted 11 lines
arch/x86/kernel/cpu/resctrl/internal.h +2
-1@@ -704,5 +704,8 @@ unsigned int mon_event_config_index_get(u32 evtid);int resctrl_arch_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d,enum resctrl_event_id evtid,u32 rmid,u32 closid,u32 cntr_id,bool assign); - +int rdtgroup_assign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp, +struct rdt_mon_domain *d,enum resctrl_event_id evtid);
Could you please be consistent in the ordering of parameters?
int rdtgroup_assign_cntr_event(struct rdt_resource *r, struct rdt_mon_domain *d,
struct rdtgroup *rdtgrp, enum resctrl_event_id evtid);
Quoted 23 lines
arch/x86/kernel/cpu/resctrl/internal.h +2
-0+struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid, +u32 rmid,enum resctrl_event_id evtid);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */ arch/x86/kernel/cpu/resctrl/monitor.c +2
-2@@ -575,8 +575,8 @@ void free_rmid(u32 closid, u32 rmid)list_add_tail (&entry->list, &rmid_free_lru); } -static struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid, -u32 rmid,enum resctrl_event_id evtid) +struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid, +u32 rmid,enum resctrl_event_id evtid) {u32 idx =resctrl_arch_rmid_idx_encode (closid, rmid);arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 1931
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0@@ -1927,6 +1927,116 @@ int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,return 0 ; } +/* +* Configure the counter for the event, RMID pair for the domain.
This description can be more helpful ... it essentially just re-writes function header.
Quoted 37 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +37
-0+*/ +static int resctrl_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d, +enum resctrl_event_id evtid,u32 rmid,u32 closid, +u32 cntr_id,bool assign) +{ +struct mbm_state *m; +int ret; + + ret =resctrl_arch_config_cntr (r, d, evtid, rmid, closid, cntr_id, assign); +if (ret) +return ret; + + m =get_mbm_state (d, closid, rmid, evtid); +if (m) +memset (m,0 ,sizeof (struct mbm_state )); + +return ret; +} + +static bool mbm_cntr_assigned (struct rdt_resource *r,struct rdt_mon_domain *d, +struct rdtgroup *rdtgrp,enum resctrl_event_id evtid) +{ +int cntr_id; + +for (cntr_id =0 ; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) { +if (d->cntr_cfg[cntr_id].rdtgrp == rdtgrp && + d->cntr_cfg[cntr_id].evtid == evtid) +return true; + } + +return false; +} + +static int mbm_cntr_alloc (struct rdt_resource *r,struct rdt_mon_domain *d, +struct rdtgroup *rdtgrp,enum resctrl_event_id evtid) +{ +int cntr_id;
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 1978
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+ +for (cntr_id =0 ; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) { +if (!d->cntr_cfg[cntr_id].rdtgrp) { + d->cntr_cfg[cntr_id].rdtgrp = rdtgrp; + d->cntr_cfg[cntr_id].evtid = evtid; +return cntr_id; + } + } + +return -EINVAL ;
This can be -ENOSPC
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 1991
Quoted 13 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +13
-0+} + +static void mbm_cntr_free (struct rdt_resource *r,struct rdt_mon_domain *d, +struct rdtgroup *rdtgrp,enum resctrl_event_id evtid) +{ +int cntr_id; + +for (cntr_id =0 ; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) { +if (d->cntr_cfg[cntr_id].rdtgrp == rdtgrp && + d->cntr_cfg[cntr_id].evtid == evtid) +memset (&d->cntr_cfg[cntr_id],0 ,sizeof (struct mbm_cntr_cfg )); + } +}
From what I can tell the counter ID is always available when the counter is freed so it can just be freed directly without looping over array?
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 1995
Quoted 4 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +4
-0+ +/* +* Assign a hardware counter to event @evtid of group @rdtgrp. +* Counter will be assigned to all the domains if rdt_mon_domain is NULL
(to be consistent) "if rdt_mon_domain is NULL" -> "if @d is NULL"
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 1996
Quoted 1 line
arch/x86/kernel/cpu/resctrl/rdtgroup.c +1
-0+* else the counter will be assigned to specific domain.
"will be assigned to specific domain" -> "will be assigned to @d"
Reinette
Re: [PATCH v10 16/24] x86/resctrl: Add interface to the assign counter
Hi Reinette,
Quoted 7 lines · Reinette Chatre
Hi Babu,
Quoted 4 lines · Babu Moger
The
mbm_cntr_assignmode offers several counters that can be assigned to an RMID, event pair and monitor the bandwidth as long as it is assigned.
Quoted 8 lines
Quoted 2 lines
Counters are managed at the domain level. Introduce the interface to allocate/free/assign the counters.
Changelog of previous patch also claimed to "Provide the interface to assign the counter ids to RMID." Please let changelogs describe the change more accurately.
(This still does not provide a user interface so what is meant by interface is unclear)
How about this?
The mbm_cntr_assign mode offers several counters that can be assigned to an RMID, event pair and monitor the bandwidth as long as it is assigned.
Counters are managed at the domain level. Introduce the functionality to allocate/free/assign the counters.
If the user requests assignments across all domains, assignments will abort on first failure. The error will be logged in /sys/fs/resctrl/info/last_cmd_status.
Quoted 16 lines
arch/x86/kernel/cpu/resctrl/internal.h unsigned int mon_event_config_index_get(u32 evtid); · line 708
Quoted 13 lines
arch/x86/kernel/cpu/resctrl/internal.h +2
-1@@ -704,5 +704,8 @@ unsigned int mon_event_config_index_get(u32 evtid);int resctrl_arch_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d,enum resctrl_event_id evtid,u32 rmid,u32 closid,u32 cntr_id,bool assign); - +int rdtgroup_assign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp, +struct rdt_mon_domain *d,enum resctrl_event_id evtid);Could you please be consistent in the ordering of parameters?
Quoted 2 lines
int rdtgroup_assign_cntr_event(struct
rdt_resource*r, structrdt_mon_domain*d,struct rdtgroup *rdtgrp, enum resctrl_event_id evtid);
Sure.
Quoted 27 lines
Quoted 27 lines
arch/x86/kernel/cpu/resctrl/internal.h +2
-0+struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid, +u32 rmid,enum resctrl_event_id evtid);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */ arch/x86/kernel/cpu/resctrl/monitor.c +2
-2@@ -575,8 +575,8 @@ void free_rmid(u32 closid, u32 rmid)list_add_tail (&entry->list, &rmid_free_lru); } -static struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid, -u32 rmid,enum resctrl_event_id evtid) +struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid, +u32 rmid,enum resctrl_event_id evtid) {u32 idx =resctrl_arch_rmid_idx_encode (closid, rmid);arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -1927,6 +1927,116 @@ int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,return 0 ; }
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 1931
Quoted 2 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0+/* +* Configure the counter for the event, RMID pair for the domain. This description can be more helpful ... it essentially just re-writes function header.
I can drop this. There is not much to explain here. Code seems easy to follow.
Quoted 42 lines
Quoted 42 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +41
-0+*/ +static int resctrl_config_cntr (struct rdt_resource *r,struct rdt_mon_domain *d, +enum resctrl_event_id evtid,u32 rmid,u32 closid, +u32 cntr_id,bool assign) +{ +struct mbm_state *m; +int ret; + + ret =resctrl_arch_config_cntr (r, d, evtid, rmid, closid, cntr_id, assign); +if (ret) +return ret; + + m =get_mbm_state (d, closid, rmid, evtid); +if (m) +memset (m,0 ,sizeof (struct mbm_state )); + +return ret; +} + +static bool mbm_cntr_assigned (struct rdt_resource *r,struct rdt_mon_domain *d, +struct rdtgroup *rdtgrp,enum resctrl_event_id evtid) +{ +int cntr_id; + +for (cntr_id =0 ; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) { +if (d->cntr_cfg[cntr_id].rdtgrp == rdtgrp && + d->cntr_cfg[cntr_id].evtid == evtid) +return true; + } + +return false; +} + +static int mbm_cntr_alloc (struct rdt_resource *r,struct rdt_mon_domain *d, +struct rdtgroup *rdtgrp,enum resctrl_event_id evtid) +{ +int cntr_id; + +for (cntr_id =0 ; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) { +if (!d->cntr_cfg[cntr_id].rdtgrp) { + d->cntr_cfg[cntr_id].rdtgrp = rdtgrp;
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 1978
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-0+ d->cntr_cfg[cntr_id].evtid = evtid; +return cntr_id; + } + } + +return -EINVAL ;This can be
-ENOSPC
Sure.
Quoted 15 lines
Quoted 14 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +13
-0+} + +static void mbm_cntr_free (struct rdt_resource *r,struct rdt_mon_domain *d, +struct rdtgroup *rdtgrp,enum resctrl_event_id evtid) +{ +int cntr_id; + +for (cntr_id =0 ; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) { +if (d->cntr_cfg[cntr_id].rdtgrp == rdtgrp && + d->cntr_cfg[cntr_id].evtid == evtid) +memset (&d->cntr_cfg[cntr_id],0 ,sizeof (struct mbm_cntr_cfg )); + } +}
Quoted 2 lines
Quoted 1 line
From what I can tell the counter ID is always available when the counter is freed so
it can just be freed directly without looping over array?
Yes. With immediate return on every individual failure, we can do this easily.
Quoted 7 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 1995
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +4
-0+ +/* +* Assign a hardware counter to event @evtid of group @rdtgrp. +* Counter will be assigned to all the domains if rdt_mon_domain is NULL (to be consistent) "if
rdt_mon_domainis NULL" -> "if @d is NULL"
Sure.
Quoted 4 lines
Quoted 2 lines
+ * else the counter will be assigned to specific domain.
"will be assigned to specific domain" -> "will be assigned to @d"
Sure.
Quoted 4 lines
Reinette
Babu Moger
reviewerPATCH v10 17/24 x86/resctrl: Add the interface to unassign a counter
In reply to Babu MogerThe mbm_cntr_assign mode provides a limited number of hardware counters that can be assigned to an RMID, event pair to monitor bandwidth while assigned. If all counters are in use, the kernel will show an error
message: "Out of MBM assignable counters" when a new assignment is requested. To make space for a new assignment, users must unassign an already assigned counter.
Introduce an interface that allows for the unassignment of counter IDs from the domain.
---
v10: Patch changed again.
Counters are managed at the domain based on the discussion.
https://lore.kernel.org/lkml/CALPaoCj+zWq1vkHVbXYP0znJbe6Ke3PXPWjtri5AFgD9cQDCUg@mail.gmail.com/
commit message update.
v9: Changes related to addition of new function resctrl_config_cntr().
The removed rdtgroup_mbm_cntr_is_assigned() as it was introduced already.
Text changes to take care comments.
v8: Renamed rdtgroup_mbm_cntr_is_assigned to mbm_cntr_assigned_to_domain
Added return error handling in resctrl_arch_config_cntr().
v7: Merged rdtgroup_unassign_cntr and rdtgroup_free_cntr functions.
Renamed rdtgroup_mbm_cntr_test() to rdtgroup_mbm_cntr_is_assigned(). Reworded the commit log little bit.
v6: Removed mbm_cntr_free from this patch.
Added counter test in all the domains and free if it is not assigned to any domains.
v5: Few name changes to match cntr_id.
Changed the function names to rdtgroup_unassign_cntr More comments on commit log.
v4: Added domain specific unassign feature.
Few name changes.
v3: Removed the static from the prototype of rdtgroup_unassign_abmc.
The function is not called directly from user anymore. These changes are related to global assignment interface.
v2: No changes.
--- arch/x86/kernel/cpu/resctrl/internal.h | 2 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 52 ++++++++++++++++++++++++++ 2 files changed, 54 insertions(+)
arch/x86/kernel/cpu/resctrl/internal.h +2 -0
@@ -706,6 +706,8 @@ int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, u32 cntr_id, bool assign);int rdtgroup_assign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp,struct rdt_mon_domain *d,enum resctrl_event_id evtid); +int rdtgroup_unassign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp, +struct rdt_mon_domain *d,enum resctrl_event_id evtid);struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid,u32 rmid,enum resctrl_event_id evtid);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */
arch/x86/kernel/cpu/resctrl/rdtgroup.c +52 -0
64 lines not on this page · raw message
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 17/24] x86/resctrl: Add the interface to unassign a counter
Hi Babu,
Quoted 9 lines · Babu Moger
The
mbm_cntr_assignmode provides a limited number of hardware counters that can be assigned to an RMID, event pair to monitor bandwidth while assigned. If all counters are in use, the kernel will show an error
message: "Out of MBM assignable counters" when a new assignment is requested. To make space for a new assignment, users must unassign an already assigned counter.Introduce an interface that allows for the unassignment of counter IDs from the domain.
Subject and changelog claims this introduces an interface, there is no new resctrl interface introduced here. Can this be more specific?
Quoted 13 lines
Signed-off-by Babu Moger <[email protected]>---
--- arch/x86/kernel/cpu/resctrl/internal.h | 2 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 52 ++++++++++++++++++++++++++ 2 files changed, 54 insertions(+)arch/x86/kernel/cpu/resctrl/internal.h +0
-0
arch/x86/kernel/cpu/resctrl/internal.h int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 710
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/internal.h +2
-0@@ -706,6 +706,8 @@ int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, u32 cntr_id, bool assign);int rdtgroup_assign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp,struct rdt_mon_domain *d,enum resctrl_event_id evtid); +int rdtgroup_unassign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp, +struct rdt_mon_domain *d,enum resctrl_event_id evtid);
(please use consistent parameter ordering)
Quoted 13 lines
arch/x86/kernel/cpu/resctrl/internal.h +0
-0struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid,u32 rmid,enum resctrl_event_id evtid);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */ arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0@@ -1990,6 +1990,20 @@ static void mbm_cntr_free(struct rdt_resource *r, struct rdt_mon_domain *d, } } +static int mbm_cntr_get (struct rdt_resource *r,struct rdt_mon_domain *d, +struct rdtgroup *rdtgrp,enum resctrl_event_id evtid)
arch/x86/kernel/cpu/resctrl/rdtgroup.c static void mbm_cntr_free(struct rdt_resource *r, struct rdt_mon_domain *d, · line 2004
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+{ +int cntr_id; + +for (cntr_id =0 ; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) { +if (d->cntr_cfg[cntr_id].rdtgrp == rdtgrp && + d->cntr_cfg[cntr_id].evtid == evtid) +return cntr_id; + } + +return -EINVAL ;
This could be -ENOENT?
arch/x86/kernel/cpu/resctrl/rdtgroup.c static void mbm_cntr_free(struct rdt_resource *r, struct rdt_mon_domain *d, · line 2005
Quoted 1 line
arch/x86/kernel/cpu/resctrl/rdtgroup.c +1
-0+}
mbm_cntr_get() seems to be essentially a duplicate of mbm_cntr_assigned() that returns actual counter ID instrad of true/false. Could only one be used?
arch/x86/kernel/cpu/resctrl/rdtgroup.c int rdtgroup_assign_cntr_event(struct rdt_resource *r, struct rdtgroup *rdtgrp, · line 2057
Quoted 12 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +5
-0+/* * Assign a hardware counter to event @evtid of group @rdtgrp. * Counter will be assigned to all the domains if rdt_mon_domain is NULL @@ -2037,6 +2051,44 @@ int rdtgroup_assign_cntr_event(struct rdt_resource *r, struct rdtgroup *rdtgrp,return ret; } +/* +* Unassign a hardware counter associated with @evtid from the domain and +* the group. Unassign the counters from all the domains if rdt_mon_domain +* is NULL else unassign from the specific domain.
(same comment as previous patch about consistency in referring to function parameters)
arch/x86/kernel/cpu/resctrl/rdtgroup.c int rdtgroup_assign_cntr_event(struct rdt_resource *r, struct rdtgroup *rdtgrp, · line 2070
Quoted 13 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +13
-0+*/ +int rdtgroup_unassign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp, +struct rdt_mon_domain *d,enum resctrl_event_id evtid) +{ +int cntr_id, ret =0 ; + +if (!d) { +list_for_each_entry (d, &r->mon_domains, hdr.list) { +if (!mbm_cntr_assigned (r, d, rdtgrp, evtid)) +continue ; + + cntr_id =mbm_cntr_get (r, d, rdtgrp, evtid); +
It seems unnecessary to loop over array twice here. mbm_cntr_assigned() seems unnecessary. Return value of mbm_cntr_get() can be used to determine if it is assigned or not?
arch/x86/kernel/cpu/resctrl/rdtgroup.c int rdtgroup_assign_cntr_event(struct rdt_resource *r, struct rdtgroup *rdtgrp, · line 2074
Quoted 4 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +4
-0+ ret =resctrl_config_cntr (r, d, evtid, rdtgrp->mon.rmid, + rdtgrp->closid, cntr_id, false); +if (!ret) +mbm_cntr_free (r, d, rdtgrp, evtid);
... and by providing cntr_id to mbm_cntr_free() another unnecessary loop can be avoided.
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+ } + }else { +if (!mbm_cntr_assigned (r, d, rdtgrp, evtid)) + goto out_done_unassign; + + cntr_id =mbm_cntr_get (r, d, rdtgrp, evtid); + + ret =resctrl_config_cntr (r, d, evtid, rdtgrp->mon.rmid, + rdtgrp->closid, cntr_id, false); +if (!ret)
arch/x86/kernel/cpu/resctrl/rdtgroup.c int rdtgroup_assign_cntr_event(struct rdt_resource *r, struct rdtgroup *rdtgrp, · line 2094
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +7
-0+mbm_cntr_free (r, d, rdtgrp, evtid); + } + +out_done_unassign: +return ret; +} +/* rdtgroup information files for one cache resource. */ static struct rftype res_common_files[] = { {
Reinette
Re: [PATCH v10 17/24] x86/resctrl: Add the interface to unassign a counter
Hi Reinette,
Quoted 10 lines · Reinette Chatre
Hi Babu,
Quoted 7 lines · Babu Moger
The
mbm_cntr_assignmode provides a limited number of hardware counters that can be assigned to an RMID, event pair to monitor bandwidth while assigned. If all counters are in use, the kernel will show an error
message: "Out of MBM assignable counters" when a new assignment is requested. To make space for a new assignment, users must unassign an already assigned counter.
Quoted 5 lines
Quoted 2 lines
Introduce an interface that allows for the unassignment of counter IDs from the domain.
Subject and changelog claims this introduces an interface, there is no new resctrl interface introduced here. Can this be more specific?
Sure. Let me rewrite the subject and description.
Quoted 9 lines
Quoted 9 lines
Signed-off-by Babu Moger <[email protected]>---
--- arch/x86/kernel/cpu/resctrl/internal.h | 2 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 52 ++++++++++++++++++++++++++ 2 files changed, 54 insertions(+)
Quoted 12 lines
arch/x86/kernel/cpu/resctrl/internal.h int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, · line 710
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/internal.h +2
-0@@ -706,6 +706,8 @@ int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d, u32 cntr_id, bool assign);int rdtgroup_assign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp,struct rdt_mon_domain *d,enum resctrl_event_id evtid); +int rdtgroup_unassign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp, +struct rdt_mon_domain *d,enum resctrl_event_id evtid);(please use consistent parameter ordering)
Sure.
Quoted 12 lines
Quoted 12 lines
arch/x86/kernel/cpu/resctrl/internal.h +0
-0struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid,u32 rmid,enum resctrl_event_id evtid);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */ arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -1990,6 +1990,20 @@ static void mbm_cntr_free(struct rdt_resource *r, struct rdt_mon_domain *d, } }
Quoted 14 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static void mbm_cntr_free(struct rdt_resource *r, struct rdt_mon_domain *d, · line 2004
Quoted 12 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +12
-0+static int mbm_cntr_get (struct rdt_resource *r,struct rdt_mon_domain *d, +struct rdtgroup *rdtgrp,enum resctrl_event_id evtid) +{ +int cntr_id; + +for (cntr_id =0 ; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) { +if (d->cntr_cfg[cntr_id].rdtgrp == rdtgrp && + d->cntr_cfg[cntr_id].evtid == evtid) +return cntr_id; + } + +return -EINVAL ;This could be
-ENOENT?
Sure.
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static void mbm_cntr_free(struct rdt_resource *r, struct rdt_mon_domain *d, · line 2005
Quoted 2 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +1
-0+}
mbm_cntr_get()seems to be essentially a duplicate ofmbm_cntr_assigned()that returns actual counter ID instrad of true/false. Could only one be used?
Yes. We can use mbm_cntr_get() alone.
Quoted 9 lines
Quoted 9 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +1
-0+/* * Assign a hardware counter to event @evtid of group @rdtgrp. * Counter will be assigned to all the domains if rdt_mon_domain is NULL @@ -2037,6 +2051,44 @@ int rdtgroup_assign_cntr_event(struct rdt_resource *r, struct rdtgroup *rdtgrp,return ret; }
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c int rdtgroup_assign_cntr_event(struct rdt_resource *r, struct rdtgroup *rdtgrp, · line 2057
Quoted 4 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +4
-0+/* +* Unassign a hardware counter associated with @evtid from the domain and +* the group. Unassign the counters from all the domains if rdt_mon_domain +* is NULL else unassign from the specific domain. (same comment as previous patch about consistency in referring to function parameters)
Sure.
Quoted 9 lines
Quoted 9 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +9
-0+*/ +int rdtgroup_unassign_cntr_event (struct rdt_resource *r,struct rdtgroup *rdtgrp, +struct rdt_mon_domain *d,enum resctrl_event_id evtid) +{ +int cntr_id, ret =0 ; + +if (!d) { +list_for_each_entry (d, &r->mon_domains, hdr.list) { +if (!mbm_cntr_assigned (r, d, rdtgrp, evtid))
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c int rdtgroup_assign_cntr_event(struct rdt_resource *r, struct rdtgroup *rdtgrp, · line 2070
Quoted 4 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +4
-0+continue ; + + cntr_id =mbm_cntr_get (r, d, rdtgrp, evtid); +It seems unnecessary to loop over array twice here.
mbm_cntr_assigned()seems unnecessary. Return value ofmbm_cntr_get()can be used to determine if it is assigned or not?
Yes. Sure.
Quoted 7 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c int rdtgroup_assign_cntr_event(struct rdt_resource *r, struct rdtgroup *rdtgrp, · line 2074
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +4
-0+ ret =resctrl_config_cntr (r, d, evtid, rdtgrp->mon.rmid, + rdtgrp->closid, cntr_id, false); +if (!ret) +mbm_cntr_free (r, d, rdtgrp, evtid);... and by providing
cntr_idtombm_cntr_free()another unnecessary loop can be avoided.
Sure.
Quoted 24 lines
Quoted 11 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+ } + }else { +if (!mbm_cntr_assigned (r, d, rdtgrp, evtid)) + goto out_done_unassign; + + cntr_id =mbm_cntr_get (r, d, rdtgrp, evtid); + + ret =resctrl_config_cntr (r, d, evtid, rdtgrp->mon.rmid, + rdtgrp->closid, cntr_id, false); +if (!ret)arch/x86/kernel/cpu/resctrl/rdtgroup.c int rdtgroup_assign_cntr_event(struct rdt_resource *r, struct rdtgroup *rdtgrp, · line 2094
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +7
-0+mbm_cntr_free (r, d, rdtgrp, evtid); + } + +out_done_unassign: +return ret; +} +/* rdtgroup information files for one cache resource. */ static struct rftype res_common_files[] = { {Reinette
Babu Moger
reviewerPATCH v10 18/24 x86/resctrl: Auto assign/unassign counters when mbm_cntr_assign is enabled
In reply to Babu MogerAssign/unassign counters on resctrl group creation/deletion. Two counters are required per group, one for MBM total event and one for MBM local event.
There are a limited number of counters available for assignment. If these counters are exhausted, the kernel will display the error message: "Out of MBM assignable counters". However, it is not necessary to fail the creation of a group due to assignment failures. Users have the flexibility to modify the assignments at a later time.
---
v10: Assigned the counter before exposing the event files.
Moved the call rdtgroup_assign_cntrs() inside mkdir_rdt_prepare_rmid_alloc(). This is called both CNTR_MON and MON group creation.
Call mbm_cntr_reset() when unmounted to clear all the assignments. Taken care of few other feedback comments.
v9: Changed rdtgroup_assign_cntrs() and rdtgroup_unassign_cntrs() to return void.
Updated couple of rdtgroup_unassign_cntrs() calls properly. Updated function comments.
v8: Renamed rdtgroup_assign_grp to rdtgroup_assign_cntrs.
Renamed rdtgroup_unassign_grp to rdtgroup_unassign_cntrs. Fixed the problem with unassigning the child MON groups of CTRL_MON group.
v7: Reworded the commit message.
Removed the reference of ABMC with mbm_cntr_assign. Renamed the function rdtgroup_assign_cntrs to rdtgroup_assign_grp.
v6: Removed the redundant comments on all the calls of
rdtgroup_assign_cntrs. Updated the commit message.
Dropped printing error message on every call of rdtgroup_assign_cntrs.
v5: Removed the code to enable/disable ABMC during the mount.
That will be another patch.
Added arch callers to get the arch specific data. Renamed fuctions to match the other abmc function. Added code comments for assignment failures.
v4: Few name changes based on the upstream discussion.
Commit message update.
v3: This is a new patch. Patch addresses the upstream comment to enable
ABMC feature by default if the feature is available.
--- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 81 +++++++++++++++++++++++++- 1 file changed, 79 insertions(+), 2 deletions(-)
arch/x86/kernel/cpu/resctrl/rdtgroup.c +79 -2
@@ -920,6 +920,25 @@ static int rdtgroup_available_mbm_cntrs_show(struct kernfs_open_file *of,return ret; } +static void mbm_cntr_reset (struct rdt_resource *r) +{ +struct rdt_mon_domain *dom; + +/* +* Hardware counters will reset after switching the monitor mode. +* Reset the architectural state so that reading of hardware +* counter is not considered as an overflow in the next update. +* Also reset the domain counter bitmap. +*/ +if (is_mbm_enabled () && r->mon.mbm_cntr_assignable) { +list_for_each_entry (dom, &r->mon_domains, hdr.list) { +memset (dom->cntr_cfg,0 , +sizeof (*dom->cntr_cfg) * r->mon.num_mbm_cntrs); +resctrl_arch_reset_rmid_all (r, dom); + } + } +} +#ifdef CONFIG_PROC_CPU_RESCTRL /*
@@ -2969,6 +2988,46 @@ static void schemata_list_destroy(void) } } +/* +* Called when a new group is created. If "mbm_cntr_assign" mode is enabled, +* counters are automatically assigned. Each group can accommodate two counters: +* one for the total event and one for the local event. Assignments may fail +* due to the limited number of counters. However, it is not necessary to fail +* the group creation and thus no failure is returned. Users have the option +* to modify the counter assignments after the group has been created. +*/ +static void rdtgroup_assign_cntrs (struct rdtgroup *rdtgrp) +{ +struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3 ].r_resctrl; + +if (!resctrl_arch_mbm_cntr_assign_enabled (r)) +return ; + +if (is_mbm_total_enabled ()) +rdtgroup_assign_cntr_event (r, rdtgrp,NULL ,QOS_L3_MBM_TOTAL_EVENT_ID ); + +if (is_mbm_local_enabled ()) +rdtgroup_assign_cntr_event (r, rdtgrp,NULL ,QOS_L3_MBM_LOCAL_EVENT_ID ); +} + +/* +* Called when a group is deleted. Counters are unassigned if it was in +* assigned state. +*/ +static void rdtgroup_unassign_cntrs (struct rdtgroup *rdtgrp) +{ +struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3 ].r_resctrl; + +if (!resctrl_arch_mbm_cntr_assign_enabled (r)) +return ; + +if (is_mbm_total_enabled ()) +rdtgroup_unassign_cntr_event (r, rdtgrp,NULL ,QOS_L3_MBM_TOTAL_EVENT_ID ); + +if (is_mbm_local_enabled ()) +rdtgroup_unassign_cntr_event (r, rdtgrp,NULL ,QOS_L3_MBM_LOCAL_EVENT_ID ); +} +static int rdt_get_tree (struct fs_context *fc) {struct rdt_fs_context *ctx =rdt_fc2context (fc);
@@ -3023,6 +3082,8 @@ static int rdt_get_tree(struct fs_context *fc)if (ret <0 ) goto out_info; +rdtgroup_assign_cntrs (&rdtgroup_default); + ret =mkdir_mondata_all (rdtgroup_default.kn, &rdtgroup_default, &kn_mondata);if (ret <0 )
@@ -3058,8 +3119,10 @@ static int rdt_get_tree(struct fs_context *fc) out_psl:rdt_pseudo_lock_release (); out_mondata: -if (resctrl_arch_mon_capable ()) +if (resctrl_arch_mon_capable ()) {kernfs_remove (kn_mondata); +rdtgroup_unassign_cntrs (&rdtgroup_default); + } out_mongrp:if (resctrl_arch_mon_capable ())kernfs_remove (kn_mongrp);
@@ -3238,6 +3301,7 @@ static void free_all_child_rdtgrp(struct rdtgroup *rdtgrp) head = &rdtgrp->mon.crdtgrp_list;list_for_each_entry_safe (sentry, stmp, head, mon.crdtgrp_list) { +rdtgroup_unassign_cntrs (sentry);free_rmid (sentry->closid, sentry->mon.rmid);list_del (&sentry->mon.crdtgrp_list);
@@ -3278,6 +3342,8 @@ static void rmdir_all_sub(void)cpumask_or (&rdtgroup_default.cpu_mask, &rdtgroup_default.cpu_mask, &rdtgrp->cpu_mask); +rdtgroup_unassign_cntrs (rdtgrp); +free_rmid (rdtgrp->closid, rdtgrp->mon.rmid);kernfs_remove (rdtgrp->kn);
@@ -3309,6 +3375,8 @@ static void rdt_kill_sb(struct super_block *sb)for_each_alloc_capable_rdt_resource (r)reset_all_ctrls (r);rmdir_all_sub (); +rdtgroup_unassign_cntrs (&rdtgroup_default); +mbm_cntr_reset (&rdt_resources_all[RDT_RESOURCE_L3 ].r_resctrl);rdt_pseudo_lock_release (); rdtgroup_default.mode =RDT_MODE_SHAREABLE ;schemata_list_destroy ();
@@ -3772,6 +3840,8 @@ static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp) } rdtgrp->mon.rmid = ret; +rdtgroup_assign_cntrs (rdtgrp); + ret =mkdir_mondata_all (rdtgrp->kn, rdtgrp, &rdtgrp->mon.mon_data_kn);if (ret) {rdt_last_cmd_puts ("kernfs subdir error\n" );
@@ -3784,8 +3854,10 @@ static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp)static void mkdir_rdt_prepare_rmid_free (struct rdtgroup *rgrp) { -if (resctrl_arch_mon_capable ()) +if (resctrl_arch_mon_capable ()) { +rdtgroup_unassign_cntrs (rgrp);free_rmid (rgrp->closid, rgrp->mon.rmid); + } } static int mkdir_rdt_prepare(struct kernfs_node *parent_kn,
@@ -4044,6 +4116,9 @@ static int rdtgroup_rmdir_mon(struct rdtgroup *rdtgrp, cpumask_var_t tmpmask)update_closid_rmid (tmpmask,NULL ); rdtgrp->flags =RDT_DELETED ; + +rdtgroup_unassign_cntrs (rdtgrp); +free_rmid (rdtgrp->closid, rdtgrp->mon.rmid);/*
@@ -4090,6 +4165,8 @@ static int rdtgroup_rmdir_ctrl(struct rdtgroup *rdtgrp, cpumask_var_t tmpmask)cpumask_or (tmpmask, tmpmask, &rdtgrp->cpu_mask);update_closid_rmid (tmpmask,NULL ); +rdtgroup_unassign_cntrs (rdtgrp); +free_rmid (rdtgrp->closid, rdtgrp->mon.rmid);closid_free (rdtgrp->closid);
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 18/24] x86/resctrl: Auto assign/unassign counters when mbm_cntr_assign is enabled
Hi Babu,
Quoted 29 lines · Babu Moger
Assign/unassign counters on resctrl group creation/deletion. Two counters are required per group, one for MBM total event and one for MBM local event.
There are a limited number of counters available for assignment. If these counters are exhausted, the kernel will display the error message: "Out of MBM assignable counters". However, it is not necessary to fail the creation of a group due to assignment failures. Users have the flexibility to modify the assignments at a later time.
Signed-off-by Babu Moger <[email protected]>---
--- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 81 +++++++++++++++++++++++++- 1 file changed, 79 insertions(+), 2 deletions(-)arch/x86/kernel/cpu/resctrl/rdtgroup.c +5
-0@@ -920,6 +920,25 @@ static int rdtgroup_available_mbm_cntrs_show(struct kernfs_open_file *of,return ret; } +static void mbm_cntr_reset (struct rdt_resource *r) +{ +struct rdt_mon_domain *dom; + +/*
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_available_mbm_cntrs_show(struct kernfs_open_file *of, · line 937
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+* Hardware counters will reset after switching the monitor mode. +* Reset the architectural state so that reading of hardware +* counter is not considered as an overflow in the next update. +* Also reset the domain counter bitmap. +*/ +if (is_mbm_enabled () && r->mon.mbm_cntr_assignable) { +list_for_each_entry (dom, &r->mon_domains, hdr.list) { +memset (dom->cntr_cfg,0 , +sizeof (*dom->cntr_cfg) * r->mon.num_mbm_cntrs); +resctrl_arch_reset_rmid_all (r, dom);
This looks to be missing reset of resctrl monitor state (from get_mbm_state()).
...
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdt_get_tree(struct fs_context *fc) · line 3089
Quoted 12 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0static int rdt_get_tree (struct fs_context *fc) {struct rdt_fs_context *ctx =rdt_fc2context (fc);@@ -3023,6 +3082,8 @@ static int rdt_get_tree(struct fs_context *fc)if (ret <0 ) goto out_info; +rdtgroup_assign_cntrs (&rdtgroup_default); + ret =mkdir_mondata_all (rdtgroup_default.kn, &rdtgroup_default, &kn_mondata);if (ret <0 )
If this mkdir_mondata_all() fails it calls "goto out_mongrp" ...
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdt_get_tree(struct fs_context *fc) · line 3128
Quoted 12 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +3
-1@@ -3058,8 +3119,10 @@ static int rdt_get_tree(struct fs_context *fc) out_psl:rdt_pseudo_lock_release (); out_mondata: -if (resctrl_arch_mon_capable ()) +if (resctrl_arch_mon_capable ()) {kernfs_remove (kn_mondata); +rdtgroup_unassign_cntrs (&rdtgroup_default); + } out_mongrp:if (resctrl_arch_mon_capable ())kernfs_remove (kn_mongrp);
Looks like this will miss counter cleanup on failure of mkdir_mondata_all().
Quoted 27 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +5
-0@@ -3238,6 +3301,7 @@ static void free_all_child_rdtgrp(struct rdtgroup *rdtgrp) head = &rdtgrp->mon.crdtgrp_list;list_for_each_entry_safe (sentry, stmp, head, mon.crdtgrp_list) { +rdtgroup_unassign_cntrs (sentry);free_rmid (sentry->closid, sentry->mon.rmid);list_del (&sentry->mon.crdtgrp_list);@@ -3278,6 +3342,8 @@ static void rmdir_all_sub(void)cpumask_or (&rdtgroup_default.cpu_mask, &rdtgroup_default.cpu_mask, &rdtgrp->cpu_mask); +rdtgroup_unassign_cntrs (rdtgrp); +free_rmid (rdtgrp->closid, rdtgrp->mon.rmid);kernfs_remove (rdtgrp->kn);@@ -3309,6 +3375,8 @@ static void rdt_kill_sb(struct super_block *sb)for_each_alloc_capable_rdt_resource (r)reset_all_ctrls (r);rmdir_all_sub (); +rdtgroup_unassign_cntrs (&rdtgroup_default); +mbm_cntr_reset (&rdt_resources_all[RDT_RESOURCE_L3 ].r_resctrl);rdt_pseudo_lock_release (); rdtgroup_default.mode =RDT_MODE_SHAREABLE ;schemata_list_destroy ();
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp) · line 3847
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0@@ -3772,6 +3840,8 @@ static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp) } rdtgrp->mon.rmid = ret; +rdtgroup_assign_cntrs (rdtgrp); + ret =mkdir_mondata_all (rdtgrp->kn, rdtgrp, &rdtgrp->mon.mon_data_kn);if (ret) {rdt_last_cmd_puts ("kernfs subdir error\n" );
Cleanup of assigned counters if mkdir_mondata_all() fails seems to be missing here also.
Quoted 23 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-1@@ -3784,8 +3854,10 @@ static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp)static void mkdir_rdt_prepare_rmid_free (struct rdtgroup *rgrp) { -if (resctrl_arch_mon_capable ()) +if (resctrl_arch_mon_capable ()) { +rdtgroup_unassign_cntrs (rgrp);free_rmid (rgrp->closid, rgrp->mon.rmid); + } } static int mkdir_rdt_prepare(struct kernfs_node *parent_kn,@@ -4044,6 +4116,9 @@ static int rdtgroup_rmdir_mon(struct rdtgroup *rdtgrp, cpumask_var_t tmpmask)update_closid_rmid (tmpmask,NULL ); rdtgrp->flags =RDT_DELETED ; + +rdtgroup_unassign_cntrs (rdtgrp); +free_rmid (rdtgrp->closid, rdtgrp->mon.rmid);/*
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_rmdir_ctrl(struct rdtgroup *rdtgrp, cpumask_var_t tmpmask) · line 4172
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0@@ -4090,6 +4165,8 @@ static int rdtgroup_rmdir_ctrl(struct rdtgroup *rdtgrp, cpumask_var_t tmpmask)cpumask_or (tmpmask, tmpmask, &rdtgrp->cpu_mask);update_closid_rmid (tmpmask,NULL ); +rdtgroup_unassign_cntrs (rdtgrp); +free_rmid (rdtgrp->closid, rdtgrp->mon.rmid);closid_free (rdtgrp->closid);
Reinette
Re: [PATCH v10 18/24] x86/resctrl: Auto assign/unassign counters when mbm_cntr_assign is enabled
Hi Reinette,
Quoted 36 lines · Reinette Chatre
Hi Babu,
Quoted 33 lines · Babu Moger
Assign/unassign counters on resctrl group creation/deletion. Two counters are required per group, one for MBM total event and one for MBM local event.
There are a limited number of counters available for assignment. If these counters are exhausted, the kernel will display the error message: "Out of MBM assignable counters". However, it is not necessary to fail the creation of a group due to assignment failures. Users have the flexibility to modify the assignments at a later time.
Signed-off-by Babu Moger <[email protected]>---
--- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 81 +++++++++++++++++++++++++- 1 file changed, 79 insertions(+), 2 deletions(-)arch/x86/kernel/cpu/resctrl/rdtgroup.c +9
-0@@ -920,6 +920,25 @@ static int rdtgroup_available_mbm_cntrs_show(struct kernfs_open_file *of,return ret; } +static void mbm_cntr_reset (struct rdt_resource *r) +{ +struct rdt_mon_domain *dom; + +/* +* Hardware counters will reset after switching the monitor mode. +* Reset the architectural state so that reading of hardware +* counter is not considered as an overflow in the next update. +* Also reset the domain counter bitmap.
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_available_mbm_cntrs_show(struct kernfs_open_file *of, · line 937
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +6
-0+*/ +if (is_mbm_enabled () && r->mon.mbm_cntr_assignable) { +list_for_each_entry (dom, &r->mon_domains, hdr.list) { +memset (dom->cntr_cfg,0 , +sizeof (*dom->cntr_cfg) * r->mon.num_mbm_cntrs); +resctrl_arch_reset_rmid_all (r, dom);This looks to be missing reset of resctrl monitor state (from
get_mbm_state()).
Yes. Will do.
Quoted 10 lines
...
Quoted 7 lines
static int rdt_get_tree(struct fs_context *fc) { struct rdt_fs_context *ctx = rdt_fc2context(fc);arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -3023,6 +3082,8 @@ static int rdt_get_tree(struct fs_context *fc)if (ret <0 ) goto out_info;
Quoted 7 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdt_get_tree(struct fs_context *fc) · line 3089
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0+rdtgroup_assign_cntrs (&rdtgroup_default); + ret =mkdir_mondata_all (rdtgroup_default.kn, &rdtgroup_default, &kn_mondata);if (ret <0 )If this
mkdir_mondata_all()fails it calls "gotoout_mongrp" ...
Sure.
Quoted 15 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdt_get_tree(struct fs_context *fc) · line 3128
Quoted 13 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +3
-1@@ -3058,8 +3119,10 @@ static int rdt_get_tree(struct fs_context *fc) out_psl:rdt_pseudo_lock_release (); out_mondata: -if (resctrl_arch_mon_capable ()) +if (resctrl_arch_mon_capable ()) {kernfs_remove (kn_mondata); +rdtgroup_unassign_cntrs (&rdtgroup_default); + } out_mongrp:if (resctrl_arch_mon_capable ())kernfs_remove (kn_mongrp);Looks like this will miss counter cleanup on failure of
mkdir_mondata_all().
Sure.
Quoted 31 lines
Quoted 31 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +5
-0@@ -3238,6 +3301,7 @@ static void free_all_child_rdtgrp(struct rdtgroup *rdtgrp) head = &rdtgrp->mon.crdtgrp_list;list_for_each_entry_safe (sentry, stmp, head, mon.crdtgrp_list) { +rdtgroup_unassign_cntrs (sentry);free_rmid (sentry->closid, sentry->mon.rmid);list_del (&sentry->mon.crdtgrp_list);@@ -3278,6 +3342,8 @@ static void rmdir_all_sub(void)cpumask_or (&rdtgroup_default.cpu_mask, &rdtgroup_default.cpu_mask, &rdtgrp->cpu_mask); +rdtgroup_unassign_cntrs (rdtgrp); +free_rmid (rdtgrp->closid, rdtgrp->mon.rmid);kernfs_remove (rdtgrp->kn);@@ -3309,6 +3375,8 @@ static void rdt_kill_sb(struct super_block *sb)for_each_alloc_capable_rdt_resource (r)reset_all_ctrls (r);rmdir_all_sub (); +rdtgroup_unassign_cntrs (&rdtgroup_default); +mbm_cntr_reset (&rdt_resources_all[RDT_RESOURCE_L3 ].r_resctrl);rdt_pseudo_lock_release (); rdtgroup_default.mode =RDT_MODE_SHAREABLE ;schemata_list_destroy ();@@ -3772,6 +3840,8 @@ static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp) } rdtgrp->mon.rmid = ret;
Quoted 7 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp) · line 3847
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0+rdtgroup_assign_cntrs (rdtgrp); + ret =mkdir_mondata_all (rdtgrp->kn, rdtgrp, &rdtgrp->mon.mon_data_kn);if (ret) {rdt_last_cmd_puts ("kernfs subdir error\n" );Cleanup of assigned counters if
mkdir_mondata_all()fails seems to be missing here also.
Sure.
Thanks
Babu
Babu Moger
reviewerPATCH v10 19/24 x86/resctrl: Report "Unassigned" for MBM events in mbm_cntr_assign mode
In reply to Babu MogerIn mbm_cntr_assign mode, the hardware counter should be assigned to read the MBM events.
Report 'Unassigned' in case the user attempts to read the events without assigning the counter.
---
v10: Moved the code to check the assign state inside mon_event_read().
Fixed few text comments.
v9: Used is_mbm_event() to check the event type.
Minor user documentation update.
v8: Used MBM_EVENT_ARRAY_INDEX to get the index for the MBM event.
Documentation update to make the text generic.
v7: Moved the documentation under "mon_data".
Updated the text little bit.
v6: Added more explaination in the resctrl.rst
Added checks to detect "Unassigned" before reading RMID.
v5: New patch.
--- Documentation/arch/x86/resctrl.rst | 10 ++++++++++ arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 8 ++++++++ arch/x86/kernel/cpu/resctrl/internal.h | 2 ++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 4 ++-- 4 files changed, 22 insertions(+), 2 deletions(-)
Documentation/arch/x86/resctrl.rst +10 -0
@@ -430,6 +430,16 @@ When monitoring is enabled all MON groups will also contain: for the L3 cache they occupy). These are named "mon_sub_L3_YY" where "YY" is the node number. + When supported the mbm_cntr_assign mode allows users to assign a + counter to mon_hw_id, event pair enabling bandwidth monitoring for + as long as the counter remains assigned. The hardware will continue + tracking the assigned mon_hw_id until the user manually unassigns + it, ensuring that counters are not reset during this period. With + a limited number of counters, the system may run out of assignable + counters. In that case, MBM event counters will return 'Unassigned' + when the event is read. Users must manually assign a counter to read + the events. + "mon_hw_id": Available only with debug option. The identifier used by hardware for the monitor group. On x86 this is the RMID.
arch/x86/kernel/cpu/resctrl/ctrlmondata.c +8 -0
@@ -527,6 +527,12 @@ void mon_event_read(struct rmid_read *rr, struct rdt_resource *r,/* When picking a CPU from cpu_mask, ensure it can't race with cpuhp */ lockdep_assert_cpus_held (); +if (resctrl_arch_mbm_cntr_assign_enabled (r) &&is_mbm_event (evtid) && + !mbm_cntr_assigned (r, d, rdtgrp, evtid)) { + rr->err = -ENOENT ; +return ; + } +/* * Setup the parameters to pass to mon_event_count() to read the data. */
@@ -618,6 +624,8 @@ int rdtgroup_mondata_show(struct seq_file *m, void *arg)seq_puts (m,"Error\n" ); else if (rr.err == -EINVAL) seq_puts(m, "Unavailable\n"); + else if (rr.err == -ENOENT) + seq_puts(m, "Unassigned\n"); else seq_printf(m, "%llu\n", rr.val);
arch/x86/kernel/cpu/resctrl/internal.h +2 -0
@@ -710,4 +710,6 @@ int rdtgroup_unassign_cntr_event(struct rdt_resource *r, struct rdtgroup *rdtgrp struct rdt_mon_domain *d, enum resctrl_event_id evtid);struct mbm_state *get_mbm_state (struct rdt_mon_domain *d,u32 closid,u32 rmid,enum resctrl_event_id evtid); +bool mbm_cntr_assigned (struct rdt_resource *r,struct rdt_mon_domain *d, +struct rdtgroup *rdtgrp,enum resctrl_event_id evtid);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2 -2
@@ -1967,8 +1967,8 @@ static int resctrl_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,return ret; } -static bool mbm_cntr_assigned (struct rdt_resource *r,struct rdt_mon_domain *d, -struct rdtgroup *rdtgrp,enum resctrl_event_id evtid) +bool mbm_cntr_assigned (struct rdt_resource *r,struct rdt_mon_domain *d, +struct rdtgroup *rdtgrp,enum resctrl_event_id evtid) {int cntr_id;
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 19/24] x86/resctrl: Report "Unassigned" for MBM events in mbm_cntr_assign mode
Hi Babu,
Quoted 8 lines · Babu Moger
In
mbm_cntr_assignmode, the hardware counter should be assigned to read the MBM events.Report 'Unassigned' in case the user attempts to read the events without assigning the counter.
Signed-off-by Babu Moger <[email protected]>---
..
Documentation/arch/x86/resctrl.rst When monitoring is enabled all MON groups will also contain: · line 433
Quoted 9 lines
Documentation/arch/x86/resctrl.rst +1
-0@@ -430,6 +430,16 @@ When monitoring is enabled all MON groups will also contain: for the L3 cache they occupy). These are named "mon_sub_L3_YY" where "YY" is the node number. + When supported the mbm_cntr_assign mode allows users to assign a
"When supported" -> "When enabled"? Or perhaps just drop that and start with "mbm_cntr_assign mode allows users ..."
Quoted 17 lines
Documentation/arch/x86/resctrl.rst +9
-0+ counter to mon_hw_id, event pair enabling bandwidth monitoring for + as long as the counter remains assigned. The hardware will continue + tracking the assigned mon_hw_id until the user manually unassigns + it, ensuring that counters are not reset during this period. With + a limited number of counters, the system may run out of assignable + counters. In that case, MBM event counters will return 'Unassigned' + when the event is read. Users must manually assign a counter to read + the events. + "mon_hw_id": Available only with debug option. The identifier used by hardware for the monitor group. On x86 this is the RMID.arch/x86/kernel/cpu/resctrl/ctrlmondata.c +0
-0
arch/x86/kernel/cpu/resctrl/ctrlmondata.c void mon_event_read(struct rmid_read *rr, struct rdt_resource *r, · line 535
Quoted 9 lines
arch/x86/kernel/cpu/resctrl/ctrlmondata.c +6
-0@@ -527,6 +527,12 @@ void mon_event_read(struct rmid_read *rr, struct rdt_resource *r,/* When picking a CPU from cpu_mask, ensure it can't race with cpuhp */ lockdep_assert_cpus_held (); +if (resctrl_arch_mbm_cntr_assign_enabled (r) &&is_mbm_event (evtid) && + !mbm_cntr_assigned (r, d, rdtgrp, evtid)) { + rr->err = -ENOENT ; +return ; + } +
hmmm ... d can be NULL here after the SNC support. Since the file that needs a sum is essentially software backed I do not think assigning counters would apply to it (but it may theoretically apply to the domains it consists of). I think it may be safer to just move this check into rdtgroup_mondata_show() where it reads data for a single domain.
I am not sure if we need to change the documentation because of this. One option could be a rewording to "MBM event counters may return 'Unassigned' or 'Unavailable' when the event is read".
Reinette
Re: [PATCH v10 19/24] x86/resctrl: Report "Unassigned" for MBM events in mbm_cntr_assign mode
Hi Reinette,
Quoted 22 lines · Reinette Chatre
Hi Babu,
Quoted 8 lines · Babu Moger
In
mbm_cntr_assignmode, the hardware counter should be assigned to read the MBM events.Report 'Unassigned' in case the user attempts to read the events without assigning the counter.
Signed-off-by Babu Moger <[email protected]>---
..
Quoted 8 lines
Documentation/arch/x86/resctrl.rst +0
-0@@ -430,6 +430,16 @@ When monitoring is enabled all MON groups will also contain: for the L3 cache they occupy). These are named "mon_sub_L3_YY" where "YY" is the node number.
Quoted 4 lines
Documentation/arch/x86/resctrl.rst When monitoring is enabled all MON groups will also contain: · line 433
Quoted 1 line
Documentation/arch/x86/resctrl.rst +1
-0+ When supported the mbm_cntr_assign mode allows users to assign a"When supported" -> "When enabled"? Or perhaps just drop that and start with "
mbm_cntr_assignmode allows users ..."
ok.
Quoted 22 lines
Quoted 22 lines
Documentation/arch/x86/resctrl.rst +9
-0+ counter to mon_hw_id, event pair enabling bandwidth monitoring for + as long as the counter remains assigned. The hardware will continue + tracking the assigned mon_hw_id until the user manually unassigns + it, ensuring that counters are not reset during this period. With + a limited number of counters, the system may run out of assignable + counters. In that case, MBM event counters will return 'Unassigned' + when the event is read. Users must manually assign a counter to read + the events. + "mon_hw_id": Available only with debug option. The identifier used by hardware for the monitor group. On x86 this is the RMID.arch/x86/kernel/cpu/resctrl/ctrlmondata.c +0
-0@@ -527,6 +527,12 @@ void mon_event_read(struct rmid_read *rr, struct rdt_resource *r,/* When picking a CPU from cpu_mask, ensure it can't race with cpuhp */ lockdep_assert_cpus_held ();
Quoted 12 lines
arch/x86/kernel/cpu/resctrl/ctrlmondata.c void mon_event_read(struct rmid_read *rr, struct rdt_resource *r, · line 535
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/ctrlmondata.c +6
-0+if (resctrl_arch_mbm_cntr_assign_enabled (r) &&is_mbm_event (evtid) && + !mbm_cntr_assigned (r, d, rdtgrp, evtid)) { + rr->err = -ENOENT ; +return ; + } +hmmm ... d can be NULL here after the SNC support. Since the file that needs a sum is essentially software backed I do not think assigning counters would apply to it (but it may theoretically apply to the domains it consists of). I think it may be safer to just move this check into
rdtgroup_mondata_show()where it reads data for a single domain.
Sure.
Quoted 4 lines
I am not sure if we need to change the documentation because of this. One option could be a rewording to "MBM event counters may return 'Unassigned' or 'Unavailable' when the event is read".
ok.
Thanks
Babu
Babu Moger
reviewerPATCH v10 20/24 x86/resctrl: Introduce the interface to switch between monitor modes
In reply to Babu MogerIntroduce interface to switch between mbm_cntr_assign and default modes.
$ cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode [mbm_cntr_assign] default
To enable the "mbm_cntr_assign" mode:
$ echo "mbm_cntr_assign" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
To enable the default monitoring mode:
$ echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
MBM event counters will reset when mbm_assign_mode is changed.
---
v10: The call mbm_cntr_reset() has been moved to earlier patch.
Minor documentation update.
v9: Fixed extra spaces in user documentation.
Fixed problem changing the mode to mbm_cntr_assign mode when it is not supported. Added extra checks to detect if systems supports it. Used the rdtgroup_cntr_id_init to initialize cntr_id.
v8: Reset the internal counters after mbm_cntr_assign mode is changed.
Renamed rdtgroup_mbm_cntr_reset() to mbm_cntr_reset() Updated the documentation to make text generic.
v7: Changed the interface name to mbm_assign_mode.
Removed the references of ABMC.
Added the changes to reset global and domain bitmaps. Added the changes to reset rmid.
v6: Changed the mode name to mbm_cntr_assign.
Moved all the FS related code here.
Added changes to reset mbm_cntr_map and resctrl group counters.
v5: Change log and mode description text correction.
v4: Minor commit text changes. Keep the default to ABMC when supported.
Fixed comments to reflect changed interface "mbm_mode".
v3: New patch to address the review comments from upstream.
--- Documentation/arch/x86/resctrl.rst | 15 ++++++++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 50 +++++++++++++++++++++++++- 2 files changed, 64 insertions(+), 1 deletion(-)
Documentation/arch/x86/resctrl.rst +15 -0
@@ -290,6 +290,21 @@ with the following files: "mbm_total_bytes" or "mbm_local_bytes" will report 'Unavailable' if there is no counter associated with that event. + * To enable "mbm_cntr_assign" mode: + :: + + # echo "mbm_cntr_assign" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode + + * To enable default monitoring mode: + :: + + # echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode + + The MBM events (mbm_total_bytes and/or mbm_local_bytes) associated with + counters may reset when "mbm_assign_mode" is changed. Moving to + mbm_cntr_assign mode require users to assign the counters to the events. + Otherwise, the MBM event counters will return "Unassigned" when read. + "num_mbm_cntrs": The number of monitoring counters available for assignment when the architecture supports mbm_cntr_assign mode.
arch/x86/kernel/cpu/resctrl/rdtgroup.c +49 -1
64 lines not on this page · raw message
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 20/24] x86/resctrl: Introduce the interface to switch between monitor modes
Hi Babu,
Quoted 2 lines · Babu Moger
Introduce interface to switch between
mbm_cntr_assignand default modes.
This changelog needs context.
Quoted 11 lines
$ cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode [mbm_cntr_assign] defaultTo enable the "
mbm_cntr_assign" mode:$ echo "mbm_cntr_assign" > /sys/fs/resctrl/info/L3_MON/mbm_assign_modeTo enable the default monitoring mode:
$ echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_modeMBM event counters will reset when
mbm_assign_modeis changed.
I think it will help to elaborate on this.
I understand this as two parts. As stated, the hardware counters are reset since that is what ABMC does. In this patch
there is a mbm_cntr_reset() but that does not actually reset the counters as the above implies.
Instead, the counters are automatically reset as part of changing the mode. resctrl triggers reset of architectural and non-architectural state of the events because of the hardware counter reset.
The changelog can really do more to explain what this patch does.
Quoted 19 lines
Signed-off-by Babu Moger <[email protected]>---
--- Documentation/arch/x86/resctrl.rst | 15 ++++++++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 50 +++++++++++++++++++++++++- 2 files changed, 64 insertions(+), 1 deletion(-)Documentation/arch/x86/resctrl.rst +2
-0@@ -290,6 +290,21 @@ with the following files: "mbm_total_bytes" or "mbm_local_bytes" will report 'Unavailable' if there is no counter associated with that event. + * To enable "mbm_cntr_assign" mode: + ::
Documentation/arch/x86/resctrl.rst with the following files: · line 304
Quoted 10 lines
Documentation/arch/x86/resctrl.rst +10
-0+ + # echo "mbm_cntr_assign" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode + + * To enable default monitoring mode: + :: + + # echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode + + The MBM events (mbm_total_bytes and/or mbm_local_bytes) associated with + counters may reset when "mbm_assign_mode" is changed. Moving to
After looking at the final documentation it seems more appropriate to move this to the top of the "mbm_assign_mode" section. The top already shows how to read from the file using cat so it seems like a good match to document write to the file in the same area.
Documentation/arch/x86/resctrl.rst with the following files: · line 306
Quoted 2 lines
Documentation/arch/x86/resctrl.rst +2
-0+ mbm_cntr_assign mode require users to assign the counters to the events. + Otherwise, the MBM event counters will return "Unassigned" when read.
This portion can move to the mode it applies to.
Quoted 9 lines
Documentation/arch/x86/resctrl.rst +1
-0+ "num_mbm_cntrs": The number of monitoring counters available for assignment when the architecture supports mbm_cntr_assign mode.arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0
arch/x86/kernel/cpu/resctrl/rdtgroup.c static void mbm_cntr_reset(struct rdt_resource *r) · line 943
Quoted 5 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0@@ -939,6 +939,53 @@ static void mbm_cntr_reset(struct rdt_resource *r) } } +static ssize_t rdtgroup_mbm_assign_mode_write (struct kernfs_open_file *of, +char *buf,size_t nbytes,loff_t off)
rdtgroup_ namespace is not appropriate
Quoted 50 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +45
-0+{ +struct rdt_resource *r = of->kn->parent->priv; +int ret =0 ; +bool enable; + +/* Valid input requires a trailing newline */ +if (nbytes ==0 || buf[nbytes -1 ] !='\n' ) +return -EINVAL ; + + buf[nbytes -1 ] ='\0' ; + +cpus_read_lock (); +mutex_lock (&rdtgroup_mutex); + +rdt_last_cmd_clear (); + +if (!strcmp (buf,"default" )) { + enable =0 ; + }else if (!strcmp (buf,"mbm_cntr_assign" )) { +if (r->mon.mbm_cntr_assignable) { + enable =1 ; + }else { + ret = -EINVAL ; +rdt_last_cmd_puts ("mbm_cntr_assign mode is not supported\n" ); + goto write_exit; + } + }else { + ret = -EINVAL ; +rdt_last_cmd_puts ("Unsupported assign mode\n" ); + goto write_exit; + } + +if (enable !=resctrl_arch_mbm_cntr_assign_enabled (r)) { + ret =resctrl_arch_mbm_cntr_assign_set (r, enable); +if (!ret) +mbm_cntr_reset (r); + } + +write_exit: +mutex_unlock (&rdtgroup_mutex); +cpus_read_unlock (); + +return ret ?: nbytes; +} +#ifdef CONFIG_PROC_CPU_RESCTRL /* @@ -2222,9 +2269,10 @@ static struct rftype res_common_files[] = { },
arch/x86/kernel/cpu/resctrl/rdtgroup.c static struct rftype res_common_files[] = { · line 2278
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-1{ .name = "mbm_assign_mode", - .mode = 0444, + .mode = 0644, .kf_ops = &rdtgroup_kf_single_ops, .seq_show = rdtgroup_mbm_assign_mode_show, + .write = rdtgroup_mbm_assign_mode_write, .fflags = RFTYPE_MON_INFO, }, {
Reinette
Re: [PATCH v10 20/24] x86/resctrl: Introduce the interface to switch between monitor modes
Hi Reinette,
Quoted 7 lines · Reinette Chatre
Hi Babu,
Quoted 2 lines · Babu Moger
Introduce interface to switch between
mbm_cntr_assignand default modes.This changelog needs context.
Sure.
Quoted 23 lines
Quoted 5 lines
$ cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode [mbm_cntr_assign] defaultQuoted 7 lines
To enable the "
mbm_cntr_assign" mode:$ echo "mbm_cntr_assign" > /sys/fs/resctrl/info/L3_MON/mbm_assign_modeTo enable the default monitoring mode:
$ echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_modeMBM event counters will reset when
mbm_assign_modeis changed.I think it will help to elaborate on this.
I understand this as two parts. As stated, the hardware counters are reset since that is what ABMC does. In this patch
there is ambm_cntr_reset()but that does not actually reset the counters as the above implies.
Instead, the counters are automatically reset as part of changing the mode. resctrl triggers reset of architectural and non-architectural state of the events because of the hardware counter reset.
Quoted 1 line
The changelog can really do more to explain what this patch does.
Ok. Will do.
Quoted 27 lines
Quoted 27 lines
Signed-off-by Babu Moger <[email protected]>---
--- Documentation/arch/x86/resctrl.rst | 15 ++++++++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 50 +++++++++++++++++++++++++- 2 files changed, 64 insertions(+), 1 deletion(-)Documentation/arch/x86/resctrl.rst +9
-0@@ -290,6 +290,21 @@ with the following files: "mbm_total_bytes" or "mbm_local_bytes" will report 'Unavailable' if there is no counter associated with that event. + * To enable "mbm_cntr_assign" mode: + :: + + # echo "mbm_cntr_assign" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode + + * To enable default monitoring mode: + :: + + # echo "default" > /sys/fs/resctrl/info/L3_MON/mbm_assign_mode
Quoted 8 lines
Documentation/arch/x86/resctrl.rst with the following files: · line 304
Quoted 3 lines
Documentation/arch/x86/resctrl.rst +3
-0+ + The MBM events (mbm_total_bytes and/or mbm_local_bytes) associated with + counters may reset when "mbm_assign_mode" is changed. Moving toAfter looking at the final documentation it seems more appropriate to move this to the top of the "
mbm_assign_mode" section. The top already shows how to read from the file using cat so it seems like a good match to document write to the file in the same area.
ok.
Quoted 5 lines
Documentation/arch/x86/resctrl.rst with the following files: · line 306
Quoted 3 lines
Documentation/arch/x86/resctrl.rst +2
-0+ mbm_cntr_assign mode require users to assign the counters to the events. + Otherwise, the MBM event counters will return "Unassigned" when read.This portion can move to the mode it applies to.
ok.
Quoted 13 lines
Quoted 13 lines
Documentation/arch/x86/resctrl.rst +1
-0+ "num_mbm_cntrs": The number of monitoring counters available for assignment when the architecture supports mbm_cntr_assign mode.arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -939,6 +939,53 @@ static void mbm_cntr_reset(struct rdt_resource *r) } }
Quoted 4 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static void mbm_cntr_reset(struct rdt_resource *r) · line 943
Quoted 2 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2
-0+static ssize_t rdtgroup_mbm_assign_mode_write (struct kernfs_open_file *of, +char *buf,size_t nbytes,loff_t off)
rdtgroup_namespace is not appropriate
Will rename as resctrl_
thanks
Babu
Babu Moger
reviewerPATCH v10 21/24 x86/resctrl: Configure mbm_cntr_assign mode if supported
In reply to Babu MogerConfigure mbm_cntr_assign on AMD. 'mbm_cntr_assign' mode in AMD is ABMC (Assignable Bandwidth Monitoring Counters). It is enabled by default when supported on the system.
Ensure that the ABMC is updated on all logical processors in the resctrl domain.
---
v10: Commit text in imperative tone.
v9: Minor code change due to merge. Actual code did not change.
v8: Renamed resctrl_arch_mbm_cntr_assign_configure to
resctrl_arch_mbm_cntr_assign_set_one.
Adde r->mon_capable check.
Commit message update.v7: Introduced resctrl_arch_mbm_cntr_assign_configure() to configure.
Moved the default settings to rdt_get_mon_l3_config(). It should be done before the hotplug handler is called. It cannot be done at rdtgroup_init().
v6: Keeping the default enablement in arch init code for now.
This may need some discussion.
Renamed resctrl_arch_configure_abmc to resctrl_arch_mbm_cntr_assign_configure.
v5: New patch to enable ABMC by default.
--- arch/x86/kernel/cpu/resctrl/internal.h | 1 + arch/x86/kernel/cpu/resctrl/monitor.c | 1 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 11 +++++++++++ 3 files changed, 13 insertions(+)
arch/x86/kernel/cpu/resctrl/internal.h +1 -0
@@ -712,4 +712,5 @@ struct mbm_state *get_mbm_state(struct rdt_mon_domain *d, u32 closid, u32 rmid, enum resctrl_event_id evtid);bool mbm_cntr_assigned (struct rdt_resource *r,struct rdt_mon_domain *d,struct rdtgroup *rdtgrp,enum resctrl_event_id evtid); +void resctrl_arch_mbm_cntr_assign_set_one (struct rdt_resource *r);#endif /* _ASM_X86_RESCTRL_INTERNAL_H */
arch/x86/kernel/cpu/resctrl/monitor.c +1 -0
@@ -1237,6 +1237,7 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r) r->mon.mbm_cntr_assignable = true;cpuid_count (0x80000020 ,5 , &eax, &ebx, &ecx, &edx); r->mon.num_mbm_cntrs = (ebx &GENMASK (15 ,0 )) +1 ; + hw_res->mbm_cntr_assign_enabled = true;resctrl_file_fflags_init ("num_mbm_cntrs" ,RFTYPE_MON_INFO );resctrl_file_fflags_init ("available_mbm_cntrs" ,RFTYPE_MON_INFO ); }
arch/x86/kernel/cpu/resctrl/rdtgroup.c +11 -0
@@ -2824,6 +2824,13 @@ int resctrl_arch_mbm_cntr_assign_set(struct rdt_resource *r, bool enable)return 0 ; } +void resctrl_arch_mbm_cntr_assign_set_one (struct rdt_resource *r) +{ +struct rdt_hw_resource *hw_res =resctrl_to_arch_res (r); + +resctrl_abmc_set_one_amd (&hw_res->mbm_cntr_assign_enabled); +} +/* * We don't allow rdtgroup directories to be created anywhere * except the root directory. Thus when looking for the rdtgroup
@@ -4600,9 +4607,13 @@ int resctrl_online_mon_domain(struct rdt_resource *r, struct rdt_mon_domain *d)void resctrl_online_cpu (unsigned int cpu) { +struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3 ].r_resctrl; +mutex_lock (&rdtgroup_mutex);/* The CPU is set in default rdtgroup after online. */ cpumask_set_cpu (cpu, &rdtgroup_default.cpu_mask); +if (r->mon_capable && r->mon.mbm_cntr_assignable) +resctrl_arch_mbm_cntr_assign_set_one (r);mutex_unlock (&rdtgroup_mutex); }
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 21/24] x86/resctrl: Configure mbm_cntr_assign mode if supported
Hi Babu,
Quoted 3 lines · Babu Moger
Configure
mbm_cntr_assignon AMD. 'mbm_cntr_assign' mode in AMD is ABMC (Assignable Bandwidth Monitoring Counters). It is enabled by default when supported on the system.
Needs imperative "Enable mbm_cntr_assign mode ..."
Quoted 3 lines
Ensure that the ABMC is updated on all logical processors in the resctrl domain.
Needs imperative (for example) "Update the assignable counter mode .."
Please distinguish how it is the architecture that decides what the default mode should be. resctrl's part is to ensure that architecture gets opportunity to configure every logical processor as it comes online.
Reinette
Re: [PATCH v10 21/24] x86/resctrl: Configure mbm_cntr_assign mode if supported
Hi Reinette,
Quoted 8 lines · Reinette Chatre
Hi Babu,
Quoted 3 lines · Babu Moger
Configure
mbm_cntr_assignon AMD. 'mbm_cntr_assign' mode in AMD is ABMC (Assignable Bandwidth Monitoring Counters). It is enabled by default when supported on the system.Needs imperative "Enable
mbm_cntr_assignmode ..."
Sure.
Quoted 7 lines
Quoted 4 lines
Ensure that the ABMC is updated on all logical processors in the resctrl domain.
Needs imperative (for example) "Update the assignable counter mode .."
ok. Sure.
Quoted 5 lines
Please distinguish how it is the architecture that decides what the default mode should be. resctrl's part is to ensure that architecture gets opportunity to configure every logical processor as it comes online.
Yes. Got.
thanks
Babu
Babu Moger
reviewerPATCH v10 22/24 x86/resctrl: Update assignments on event configuration changes
In reply to Babu MogerResctrl provides option to configure events by writing to the interfaces /sys/fs/resctrl/info/L3_MON/mbm_total_bytes_config or /sys/fs/resctrl/info/L3_MON/mbm_local_bytes_config when BMEC (Bandwidth Monitoring Event Configuration) is supported.
Whenever the event configuration is updated, MBM assignments must be revised across all monitor groups within the impacted domains.
---
v10: Code changed completely with domain specific counter assignment.
Rewrite the commit message.
Added few more code comments.
v9: Again patch changed completely based on the comment.
https://lore.kernel.org/lkml/[email protected]/
Introduced resctrl_mon_event_config_set to handle IPI.
But sending another IPI inside IPI causes problem. Kernel reports SMP warning. So, introduced resctrl_arch_update_cntr() to send the command directly.
v8: Patch changed completely.
Updated the assignment on same IPI as the event is updated. Could not do the way we discussed in the thread.
https://lore.kernel.org/lkml/[email protected]/
Needed to figure out event type to update the configuration.
v7: New patch to update the assignments. Missed it earlier.
--- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 67 ++++++++++++++++++++++---- include/linux/resctrl.h | 4 +- 2 files changed, 61 insertions(+), 10 deletions(-)
arch/x86/kernel/cpu/resctrl/rdtgroup.c +58 -9
@@ -1704,26 +1704,26 @@ u32 resctrl_arch_mon_event_config_get(struct rdt_mon_domain *d,return INVALID_CONFIG_VALUE ; } -void resctrl_arch_mon_event_config_set (void *info) +void resctrl_arch_mon_event_config_set (struct rdt_mon_domain *d, +enum resctrl_event_id eventid,u32 val) { -struct mon_config_info *mon_info = info;struct rdt_hw_mon_domain *hw_dom;unsigned int index; - index =mon_event_config_index_get (mon_info->evtid); + index =mon_event_config_index_get (eventid);if (index ==INVALID_CONFIG_INDEX )return ; -wrmsr (MSR_IA32_EVT_CFG_BASE + index, mon_info->mon_config,0 ); +wrmsr (MSR_IA32_EVT_CFG_BASE + index, val,0 ); - hw_dom =resctrl_to_arch_mon_dom (mon_info->d); + hw_dom =resctrl_to_arch_mon_dom (d); -switch (mon_info->evtid) { +switch (eventid) {case QOS_L3_MBM_TOTAL_EVENT_ID : - hw_dom->mbm_total_cfg = mon_info->mon_config; + hw_dom->mbm_total_cfg = val;break ;case QOS_L3_MBM_LOCAL_EVENT_ID : - hw_dom->mbm_local_cfg = mon_info->mon_config; + hw_dom->mbm_local_cfg = val;break ;default :break ;
@@ -1825,6 +1825,54 @@ static int mbm_local_bytes_config_show(struct kernfs_open_file *of,return 0 ; } +/* +* Review the cntr_cfg domain configuration. If a matching assignment is found, +* update the counter assignment accordingly. This is within the IPI Context, +* so call resctrl_abmc_config_one_amd directly. +*/ +static void resctrl_arch_update_cntr (struct rdt_resource *r,struct rdt_mon_domain *d, +enum resctrl_event_id evtid,u32 val) +{ +struct cntr_config config; +struct rdtgroup *rdtgrp; +struct mbm_state *m; +u32 cntr_id; + +for (cntr_id =0 ; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) { + rdtgrp = d->cntr_cfg[cntr_id].rdtgrp; +if (rdtgrp && d->cntr_cfg[cntr_id].evtid == evtid) { +memset (&config,0 ,sizeof (struct cntr_config )); + config.r = r; + config.d = d; + config.evtid = evtid; + config.rmid = rdtgrp->mon.rmid; + config.closid = rdtgrp->closid; + config.cntr_id = cntr_id; + config.val = val; + config.assign =1 ; + +resctrl_abmc_config_one_amd (&config); + + m =get_mbm_state (d, rdtgrp->closid, rdtgrp->mon.rmid, evtid); +if (m) +memset (m,0 ,sizeof (struct mbm_state )); + } + } +} + +static void resctrl_mon_event_config_set (void *info) +{ +struct mon_config_info *mon_info = info; +struct rdt_mon_domain *d = mon_info->d; +struct rdt_resource *r = mon_info->r; + +resctrl_arch_mon_event_config_set (d, mon_info->evtid, mon_info->mon_config); + +/* Check if assignments needs to be updated */ +if (resctrl_arch_mbm_cntr_assign_enabled (r)) +resctrl_arch_update_cntr (r, d, mon_info->evtid, + mon_info->mon_config); +}static void mbm_config_write_domain (struct rdt_resource *r,struct rdt_mon_domain *d,u32 evtid,u32 val)
@@ -1840,6 +1888,7 @@ static void mbm_config_write_domain(struct rdt_resource *r,if (config_val ==INVALID_CONFIG_VALUE || config_val == val)return ; + mon_info.r = r; mon_info.d = d; mon_info.evtid = evtid; mon_info.mon_config = val;
@@ -1851,7 +1900,7 @@ static void mbm_config_write_domain(struct rdt_resource *r,* on one CPU is observed by all the CPUs in the domain. */ smp_call_function_any (&d->hdr.cpu_mask, - resctrl_arch_mon_event_config_set, + resctrl_mon_event_config_set, &mon_info,1 );/*
include/linux/resctrl.h +3 -1
@@ -137,6 +137,7 @@ struct rdt_mon_domain {* @mon_config: Event configuration value */ struct mon_config_info { +struct rdt_resource *r;struct rdt_mon_domain *d;enum resctrl_event_id evtid;u32 mon_config;
@@ -376,7 +377,8 @@ void resctrl_arch_reset_rmid(struct rdt_resource *r, struct rdt_mon_domain *d,*/ void resctrl_arch_reset_rmid_all (struct rdt_resource *r,struct rdt_mon_domain *d); -void resctrl_arch_mon_event_config_set (void *info); +void resctrl_arch_mon_event_config_set (struct rdt_mon_domain *d, +enum resctrl_event_id eventid,u32 val);u32 resctrl_arch_mon_event_config_get (struct rdt_mon_domain *d,enum resctrl_event_id eventid);
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 22/24] x86/resctrl: Update assignments on event configuration changes
Hi Babu,
Quoted 7 lines · Babu Moger
Resctrl provides option to configure events by writing to the interfaces
/sys/fs/resctrl/info/L3_MON/mbm_total_bytes_configor/sys/fs/resctrl/info/L3_MON/mbm_local_bytes_configwhen BMEC (Bandwidth Monitoring Event Configuration) is supported.Whenever the event configuration is updated, MBM assignments must be revised across all monitor groups within the impacted domains.
This needs imperative tone description of what this patch does.
...
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int mbm_local_bytes_config_show(struct kernfs_open_file *of, · line 1830
Quoted 7 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +3
-0@@ -1825,6 +1825,54 @@ static int mbm_local_bytes_config_show(struct kernfs_open_file *of,return 0 ; } +/* +* Review the cntr_cfg domain configuration. If a matching assignment is found, +* update the counter assignment accordingly. This is within the IPI Context,
This "Review the cntr_cfg domain configuration. If a matching assignment is found," is too vague for me to make sense of what it is trying to do. Can this be made more specific?
Quoted 57 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +46
-0+* so call resctrl_abmc_config_one_amd directly. +*/ +static void resctrl_arch_update_cntr (struct rdt_resource *r,struct rdt_mon_domain *d, +enum resctrl_event_id evtid,u32 val) +{ +struct cntr_config config; +struct rdtgroup *rdtgrp; +struct mbm_state *m; +u32 cntr_id; + +for (cntr_id =0 ; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) { + rdtgrp = d->cntr_cfg[cntr_id].rdtgrp; +if (rdtgrp && d->cntr_cfg[cntr_id].evtid == evtid) { +memset (&config,0 ,sizeof (struct cntr_config )); + config.r = r; + config.d = d; + config.evtid = evtid; + config.rmid = rdtgrp->mon.rmid; + config.closid = rdtgrp->closid; + config.cntr_id = cntr_id; + config.val = val; + config.assign =1 ; + +resctrl_abmc_config_one_amd (&config); + + m =get_mbm_state (d, rdtgrp->closid, rdtgrp->mon.rmid, evtid); +if (m) +memset (m,0 ,sizeof (struct mbm_state )); + } + } +} + +static void resctrl_mon_event_config_set (void *info) +{ +struct mon_config_info *mon_info = info; +struct rdt_mon_domain *d = mon_info->d; +struct rdt_resource *r = mon_info->r; + +resctrl_arch_mon_event_config_set (d, mon_info->evtid, mon_info->mon_config); + +/* Check if assignments needs to be updated */ +if (resctrl_arch_mbm_cntr_assign_enabled (r)) +resctrl_arch_update_cntr (r, d, mon_info->evtid, + mon_info->mon_config); +}static void mbm_config_write_domain (struct rdt_resource *r,struct rdt_mon_domain *d,u32 evtid,u32 val)@@ -1840,6 +1888,7 @@ static void mbm_config_write_domain(struct rdt_resource *r,if (config_val ==INVALID_CONFIG_VALUE || config_val == val)return ; + mon_info.r = r; mon_info.d = d; mon_info.evtid = evtid; mon_info.mon_config = val;
arch/x86/kernel/cpu/resctrl/rdtgroup.c static void mbm_config_write_domain(struct rdt_resource *r, · line 1906
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +1
-1@@ -1851,7 +1900,7 @@ static void mbm_config_write_domain(struct rdt_resource *r,* on one CPU is observed by all the CPUs in the domain. */ smp_call_function_any (&d->hdr.cpu_mask, - resctrl_arch_mon_event_config_set, + resctrl_mon_event_config_set, &mon_info,1 );/*
Reinette
Re: [PATCH v10 22/24] x86/resctrl: Update assignments on event configuration changes
Hi Reinette,
Quoted 8 lines · Reinette Chatre
Hi Babu,
Quoted 5 lines · Babu Moger
Resctrl provides option to configure events by writing to the interfaces
/sys/fs/resctrl/info/L3_MON/mbm_total_bytes_configor/sys/fs/resctrl/info/L3_MON/mbm_local_bytes_configwhen BMEC (Bandwidth Monitoring Event Configuration) is supported.
Quoted 4 lines
Quoted 2 lines
Whenever the event configuration is updated, MBM assignments must be revised across all monitor groups within the impacted domains.
This needs imperative tone description of what this patch does.
Sure.
Quoted 8 lines
...
Quoted 4 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -1825,6 +1825,54 @@ static int mbm_local_bytes_config_show(struct kernfs_open_file *of,return 0 ; }
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int mbm_local_bytes_config_show(struct kernfs_open_file *of, · line 1830
Quoted 3 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +3
-0+/* +* Review the cntr_cfg domain configuration. If a matching assignment is found, +* update the counter assignment accordingly. This is within the IPI Context, This "Review the
cntr_cfgdomain configuration. If a matching assignment is found," is too vague for me to make sense of what it is trying to do. Can this be made more specific?
Does this look ok?
Check the counter configuration in the domain. If the specific event is configured, then update the assignment with the new event configuration value. This is within the IPI Context, so call resctrl_abmc_config_one_amd directly"
Thanks,
Babu
Reinette Chatre
maintainerRe: [PATCH v10 22/24] x86/resctrl: Update assignments on event configuration changes
Hi Babu,
Quoted 31 lines · Babu
Hi Reinette,
Quoted 8 lines · Reinette Chatre
Hi Babu,
Quoted 5 lines · Babu Moger
Resctrl provides option to configure events by writing to the interfaces
/sys/fs/resctrl/info/L3_MON/mbm_total_bytes_configor/sys/fs/resctrl/info/L3_MON/mbm_local_bytes_configwhen BMEC (Bandwidth Monitoring Event Configuration) is supported.Quoted 4 lines
Quoted 2 lines
Whenever the event configuration is updated, MBM assignments must be revised across all monitor groups within the impacted domains.
This needs imperative tone description of what this patch does.
Sure.
Quoted 12 lines
...
Quoted 6 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +0
-0@@ -1825,6 +1825,54 @@ static int mbm_local_bytes_config_show(struct kernfs_open_file *of, return 0; }+/*
+ * Review thecntr_cfgdomain configuration. If a matching assignment is found,
+ * update the counter assignment accordingly. This is within the IPI Context,This "Review the
cntr_cfgdomain configuration. If a matching assignment is found," is too vague for me to make sense of what it is trying to do. Can this be made more specific?
Quoted 3 lines
Does this look ok?
Check the counter configuration in the domain. If the specific event is configured, then update the assignment with the new event configuration value. This is within the IPI Context, so call
resctrl_abmc_config_one_amddirectly"
I think it will be easier to understand what this function does if the comment is made more specific. For example:
Update hardware counter configuration after event configuration change.
Walk the hardware counters of domain @d to reconfigure all assigned counters that are monitoring @evtid with the event's new configuration @mon_config (or @config_val).
This is run on a CPU belonging to domain @d so call resctrl_abmc_config_one_amd() directly.
Looking closer at architecture specific resctrl_arch_update_cntr() the reset of non-arch state (get_mbm_state()->memset()) seems out of place. There is a resctrl_arch_reset_rmid_all() within mbm_config_write_domain() that resets all architectural state after the event configuration is changed, should the non-architectural state not also be reset at that time? It looks to me like it is something that may be needed for existing event configuration (but not an issue until Peter's new feature lands) and when done, the reset done within resctrl_arch_update_cntr() will no longer be necessary.
Something else to consider is the resctrl_arch_reset_rmid() within resctrl_abmc_config_one_amd() seems redundant on this call path since it is followed by resctrl_arch_reset_rmid_all(). resctrl_arch_reset_rmid() does one MSR write and one MSR read for every counter that needs to be reconfigured and if that is unnecessary it may be worthwhile to optimize out?
Reinette
Moger, Babu
reviewerRe: [PATCH v10 22/24] x86/resctrl: Update assignments on event configuration changes
Hi Reinette,
Quoted 42 lines · Reinette Chatre
Hi Babu,
Quoted 31 lines · Babu
Hi Reinette,
Quoted 8 lines · Reinette Chatre
Hi Babu,
Quoted 5 lines · Babu Moger
Resctrl provides option to configure events by writing to the interfaces
/sys/fs/resctrl/info/L3_MON/mbm_total_bytes_configor/sys/fs/resctrl/info/L3_MON/mbm_local_bytes_configwhen BMEC (Bandwidth Monitoring Event Configuration) is supported.Quoted 4 lines
Quoted 2 lines
Whenever the event configuration is updated, MBM assignments must be revised across all monitor groups within the impacted domains.
This needs imperative tone description of what this patch does.
Sure.
Quoted 12 lines
...
Quoted 6 lines
(quoted diff) +0
-0@@ -1825,6 +1825,54 @@ static int mbm_local_bytes_config_show(struct kernfs_open_file *of, return 0; }+/*
+ * Review thecntr_cfgdomain configuration. If a matching assignment is found,
+ * update the counter assignment accordingly. This is within the IPI Context,This "Review the
cntr_cfgdomain configuration. If a matching assignment is found," is too vague for me to make sense of what it is trying to do. Can this be made more specific?Quoted 3 lines
Does this look ok?
Check the counter configuration in the domain. If the specific event is configured, then update the assignment with the new event configuration value. This is within the IPI Context, so call
resctrl_abmc_config_one_amddirectly"I think it will be easier to understand what this function does if the comment is made more specific. For example:
Update hardware counter configuration after event configuration change.
Quoted 6 lines
Walk the hardware counters of domain @d to reconfigure all assigned counters that are monitoring @evtid with the event's new configuration @mon_config (or @config_val).
This is run on a CPU belonging to domain @d so call
resctrl_abmc_config_one_amd()directly.
Looks good. Thanks
Quoted 6 lines
Looking closer at architecture specific
resctrl_arch_update_cntr()the reset of non-arch state (get_mbm_state()->memset()) seems out of place. There is aresctrl_arch_reset_rmid_all()withinmbm_config_write_domain()that resets all architectural state after the event configuration is changed, should the non-architectural state not also be reset at that time? It looks
Moved the reset of non-arch state inside mbm_config_write_domain(). It seems to work fine. Also I can simplify the IPI code further.
(quoted diff) +0 -0
b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 5f5cf9b3a053..ce08fb718e2e 100644
arch/x86/kernel/cpu/resctrl/rdtgroup.c +0 -3
@@ -2076,9 +2076,6 @@ static void resctrl_abmc_config_one_amd(void *info) abmc_cfg.split.bw_type = config->val;wrmsrl (MSR_IA32_L3_QOS_ABMC_CFG , abmc_cfg.full); - -resctrl_arch_reset_rmid (config->r, config->d, config->closid, - config->rmid, config->evtid); } static int mbm_config_show(struct seq_file *s, struct rdt_resource *r,
u32 evtid)
@@ -2153,10 +2150,6 @@ static void resctrl_arch_update_cntr(struct rdt_resource *r, struct rdt_mon_doma
config.assign = 1;
resctrl_abmc_config_one_amd(&config);-
- m = get_mbm_state(d, rdtgrp->closid,rdtgrp->mon.rmid, evtid);
- if (m)
- memset(m, 0, sizeof(struct mbm_state));
}
} }
@@ -2178,6 +2171,7 @@ static void resctrl_mon_event_config_set(void *info)
static void mbm_config_write_domain(struct rdt_resource *r,
struct rdt_mon_domain *d, u32 evtid,
u32 val)
{
+ u32 idx_limit = resctrl_arch_system_num_rmid_idx();
struct mon_config_info mon_info = {0};
u32 config_val;@@ -2214,6 +2208,12 @@ static void mbm_config_write_domain(struct rdt_resource *r,
* mbm_local and mbm_total counts for all the RMIDs.
*/
resctrl_arch_reset_rmid_all(r, d);+
+ if (is_mbm_total_enabled())
+ memset(d->mbm_total, 0, sizeof(struct mbm_state) * idx_limit);
+
+ if (is_mbm_local_enabled())
+ memset(d->mbm_local, 0, sizeof(struct mbm_state) * idx_limit);
}
static int mon_config_write(struct rdt_resource *r, char *tok, u32 evtid)
Quoted 10 lines
to me like it is something that may be needed for existing event configuration (but not an issue until Peter's new feature lands) and when done, the reset done within
resctrl_arch_update_cntr()will no longer be necessary.Something else to consider is the
resctrl_arch_reset_rmid()withinresctrl_abmc_config_one_amd()seems redundant on this call path since it is followed byresctrl_arch_reset_rmid_all().resctrl_arch_reset_rmid()does one MSR write and one MSR read for every counter that needs to be reconfigured and if that is unnecessary it may be worthwhile to optimize out?
Yes. Removed the resctrl_arch_reset_rmid() withinresctrl_abmc_config_one_amd().
Tested the code and seems to work fine.
Signature · 2 lines
Thanks Babu Moger
Babu Moger
reviewerPATCH v10 23/24 x86/resctrl: Introduce interface to list assignment states of all the groups
In reply to Babu MogerProvide the interface to list the assignment states of all the resctrl groups in mbm_cntr_assign mode.
Example:
$ mount -t resctrl resctrl /sys/fs/resctrl/ $ cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control //0=tl;1=tl;
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 assigned
l MBM local event is assigned
tl Both total and local MBM events are assigned
_ None of the MBM events are assigned
---
v10: Changes mostly due to domain specific counter assignment.
v9: Minor parameter update in resctrl_mbm_event_assigned().
v8: Moved resctrl_mbm_event_assigned() in here as it is first used here.
Moved rdt_last_cmd_clear() before making any call. Updated the commit log.
Corrected the doc format.
v7: Renamed the interface name from 'mbm_control' to 'mbm_assign_control'
to match 'mbm_assign_mode'.
Removed Arch references from FS code.
Added rdt_last_cmd_clear() before the command processing. Added rdtgroup_mutex before all the calls.
Removed references of ABMC from FS code.
v6: The domain specific assignment can be determined looking at mbm_cntr_map.
Removed rdtgroup_abmc_dom_cfg() and rdtgroup_abmc_dom_state(). Removed the switch statement for the domain_state detection. Determined the flags incremently.
Removed special handling of default group while printing..
v5: Replaced "assignment flags" with "flags".
Changes related to mon structure.
Changes related renaming the interface from mbm_assign_control to mbm_control.
v4: Added functionality to query domain specific assigment in.
rdtgroup_abmc_dom_state().
v3: New patch.
Addresses the feedback to provide the global assignment interface.
https://lore.kernel.org/lkml/[email protected]/
--- Documentation/arch/x86/resctrl.rst | 44 ++++++++++++++++ arch/x86/kernel/cpu/resctrl/monitor.c | 1 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 71 ++++++++++++++++++++++++++ 3 files changed, 116 insertions(+)
Documentation/arch/x86/resctrl.rst +44 -0
@@ -321,6 +321,50 @@ with the following files: The number of monitoring counters available for assignment in each domain when the architecture supports mbm_cntr_assign mode. +"mbm_assign_control": + Reports the resctrl group and monitor status of each group. + + 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 assigned. + l MBM local event is assigned. + tl Both MBM total and local events are assigned. + _ None of the MBM events are assigned. + + Examples: + :: + + # 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 + + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_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 resctrl groups. All the groups have total and local MBM events + assigned on domain 0 and 1. + "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancy
arch/x86/kernel/cpu/resctrl/monitor.c +1 -0
@@ -1240,6 +1240,7 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r) hw_res->mbm_cntr_assign_enabled = true;resctrl_file_fflags_init ("num_mbm_cntrs" ,RFTYPE_MON_INFO );resctrl_file_fflags_init ("available_mbm_cntrs" ,RFTYPE_MON_INFO ); +resctrl_file_fflags_init ("mbm_assign_control" ,RFTYPE_MON_INFO ); } }
arch/x86/kernel/cpu/resctrl/rdtgroup.c +71 -0
83 lines not on this page · raw message
Signature · 1 line
2.34.1
Luck, Tony
maintainerRe: [PATCH v10 23/24] x86/resctrl: Introduce interface to list assignment states of all the groups
Quoted 18 lines · Babu Moger
arch/x86/kernel/cpu/resctrl/rdtgroup.c +18
-0+static int rdtgroup_mbm_assign_control_show (struct kernfs_open_file *of, +struct seq_file *s,void *v) +{ +struct rdt_resource *r = of->kn->parent->priv; +struct rdt_mon_domain *dom; +struct rdtgroup *rdtg; +char str[10 ]; + +cpus_read_lock (); +mutex_lock (&rdtgroup_mutex); +rdt_last_cmd_clear (); + +if (!resctrl_arch_mbm_cntr_assign_enabled (r)) { +rdt_last_cmd_puts ("mbm_cntr_assign mode is not enabled\n" ); +mutex_unlock (&rdtgroup_mutex); +cpus_read_unlock (); +return -EINVAL ; + }
arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t rdtgroup_mbm_assign_mode_write(struct kernfs_open_file *of, · line 1036
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+ +list_for_each_entry (rdtg, &rdt_all_groups, rdtgroup_list) { +struct rdtgroup *crg; + +seq_printf (s,"%s//" , rdtg->kn->name); + +list_for_each_entry (dom, &r->mon_domains, hdr.list) +seq_printf (s,"%d=%s;" , dom->hdr.id, +rdtgroup_mon_state_to_str (r, dom, rdtg, str)); +seq_putc (s,'\n' );
Other resctrl files with domain lists use ';' as a separator, not a terminator. This code results in:
//0=tl;1=tl;
rather than
//0=tl;1=tl
arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t rdtgroup_mbm_assign_mode_write(struct kernfs_open_file *of, · line 1045
Quoted 9 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +9
-0+ +list_for_each_entry (crg, &rdtg->mon.crdtgrp_list, + mon.crdtgrp_list) { +seq_printf (s,"%s/%s/" , rdtg->kn->name, crg->kn->name); + +list_for_each_entry (dom, &r->mon_domains, hdr.list) +seq_printf (s,"%d=%s;" , dom->hdr.id, +rdtgroup_mon_state_to_str (r, dom, crg, str)); +seq_putc (s,'\n' );
Ditto.
Quoted 7 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +7
-0+ } + } + +mutex_unlock (&rdtgroup_mutex); +cpus_read_unlock (); +return 0 ; +}
Re: [PATCH v10 23/24] x86/resctrl: Introduce interface to list assignment states of all the groups
Hi Tony,
Quoted 33 lines · Tony
Quoted 18 lines · Babu Moger
arch/x86/kernel/cpu/resctrl/rdtgroup.c +18
-0+static int rdtgroup_mbm_assign_control_show (struct kernfs_open_file *of, +struct seq_file *s,void *v) +{ +struct rdt_resource *r = of->kn->parent->priv; +struct rdt_mon_domain *dom; +struct rdtgroup *rdtg; +char str[10 ]; + +cpus_read_lock (); +mutex_lock (&rdtgroup_mutex); +rdt_last_cmd_clear (); + +if (!resctrl_arch_mbm_cntr_assign_enabled (r)) { +rdt_last_cmd_puts ("mbm_cntr_assign mode is not enabled\n" ); +mutex_unlock (&rdtgroup_mutex); +cpus_read_unlock (); +return -EINVAL ; + }arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t rdtgroup_mbm_assign_mode_write(struct kernfs_open_file *of, · line 1036
Quoted 10 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +10
-0+ +list_for_each_entry (rdtg, &rdt_all_groups, rdtgroup_list) { +struct rdtgroup *crg; + +seq_printf (s,"%s//" , rdtg->kn->name); + +list_for_each_entry (dom, &r->mon_domains, hdr.list) +seq_printf (s,"%d=%s;" , dom->hdr.id, +rdtgroup_mon_state_to_str (r, dom, rdtg, str)); +seq_putc (s,'\n' );Other resctrl files with domain lists use ';' as a separator, not a terminator. This code results in:
Quoted 5 lines
//0=tl;1=tl;
rather than
//0=tl;1=tl
Agree. Will correct it.
Quoted 11 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t rdtgroup_mbm_assign_mode_write(struct kernfs_open_file *of, · line 1045
Quoted 9 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +9
-0+ +list_for_each_entry (crg, &rdtg->mon.crdtgrp_list, + mon.crdtgrp_list) { +seq_printf (s,"%s/%s/" , rdtg->kn->name, crg->kn->name); + +list_for_each_entry (dom, &r->mon_domains, hdr.list) +seq_printf (s,"%d=%s;" , dom->hdr.id, +rdtgroup_mon_state_to_str (r, dom, crg, str)); +seq_putc (s,'\n' );Ditto.
Sure.
Quoted 9 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c static ssize_t rdtgroup_mbm_assign_mode_write(struct kernfs_open_file *of, · line 1052
Quoted 8 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +7
-0+ } + } + +mutex_unlock (&rdtgroup_mutex); +cpus_read_unlock (); +return 0 ; +}
thanks
Babu
Babu Moger
reviewerPATCH v10 24/24 x86/resctrl: Introduce interface to modify assignment states of the groups
In reply to Babu MogerIntroduce the interface to assign MBM events in mbm_cntr_assign mode.
Events can be enabled or disabled by writing to file /sys/fs/resctrl/info/L3_MON/mbm_assign_control
Format is similar to the list format with addition of opcode for the assignment operation.
"<CTRL_MON group>/<MON group>/<domain_id><opcode><flags>"
Format for specific type of groups:
* Default CTRL_MON group:
"//<domain_id><opcode><flags>"
* Non-default CTRL_MON group:
"<CTRL_MON group>//<domain_id><opcode><flags>"
* Child MON group of default CTRL_MON group:
"/<MON group>/<domain_id><opcode><flags>"
* Child MON group of non-default CTRL_MON group:
"<CTRL_MON group>/<MON group>/<domain_id><opcode><flags>"
Domain_id '*' will apply the flags on all the domains.
Opcode can be one of the following:
= Update the assignment to match the flags
+ Assign a new MBM event without impacting existing assignments.
- Unassign a MBM event from currently assigned events.
Assignment 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. Valid only with '=' opcode. This flag cannot
be combined with other flags.
---
v10: Fixed the issue with finding the domain in multiple iterations.
Printed error message with domain information when assign fails. Changed the variables to unsigned for processing assign state. Taken care of few format corrections.
v9: Fixed handling special case '//0=' and '//".
Removed extra strstr() call.
Added generic failure text when assignment operation fails. Corrected user documentation format texts.
v8: Moved unassign as the first action during the assign modification.
Assign none "_" takes priority. Cannot be mixed with other flags. Updated the documentation and .rst file format. htmldoc looks ok.
v7: Simplified the parsing (strsep(&token, "//") in rdtgroup_mbm_assign_control_write().
Added mutex lock in rdtgroup_mbm_assign_control_write() while processing. Renamed rdtgroup_find_grp to rdtgroup_find_grp_by_name.
Fixed rdtgroup_str_to_mon_state to return error for invalid flags. Simplified the calls rdtgroup_assign_cntr by merging few functions earlier. Removed ABMC reference in FS code.
Reinette commented about handling the combination of flags like 'lt_' and '_lt'. Not sure if we need to change the behaviour here. Processed them sequencially right now. Users have the liberty to pass the flags. Restricting it might be a problem later.
v6: Added support assign all if domain id is '*'
Fixed the allocation of counter id if it not assigned already.
v5: Interface name changed from mbm_assign_control to mbm_control.
Fixed opcode and flags combination.
'=_" is valid.
"-_" amd "+_" is not valid.
Minor message update.
Renamed the function with prefix - rdtgroup_. Corrected few documentation mistakes.
Rebase related changes after SNC support.
v4: Added domain specific assignments. Fixed the opcode parsing.
v3: New patch.
Addresses the feedback to provide the global assignment interface.
--- Documentation/arch/x86/resctrl.rst | 116 +++++++++++- arch/x86/kernel/cpu/resctrl/internal.h | 10 + arch/x86/kernel/cpu/resctrl/rdtgroup.c | 241 ++++++++++++++++++++++++- 3 files changed, 365 insertions(+), 2 deletions(-)
Documentation/arch/x86/resctrl.rst +115 -1
@@ -347,7 +347,8 @@ with the following files: t MBM total event is assigned. l MBM local event is assigned. tl Both MBM total and local events are assigned. - _ None of the MBM events are assigned. + _ None of the MBM events are assigned. Only works with opcode '=' for write + and cannot be combined with other flags. Examples: ::
@@ -365,6 +366,119 @@ with the following files: There are four resctrl groups. All the groups have total and local MBM events assigned on domain 0 and 1. + Assignment state can be updated by writing to "mbm_assign_control". + + Format is similar to the list format with addition of opcode for the + assignment operation. + + "<CTRL_MON group>/<MON group>/<domain_id><opcode><flags>" + + Format for each type of group: + + * Default CTRL_MON group: + "//<domain_id><opcode><flags>" + + * Non-default CTRL_MON group: + "<CTRL_MON group>//<domain_id><opcode><flags>" + + * Child MON group of default CTRL_MON group: + "/<MON group>/<domain_id><opcode><flags>" + + * Child MON group of non-default CTRL_MON group: + "<CTRL_MON group>/<MON group>/<domain_id><opcode><flags>" + + Domain_id '*' will apply the flags to all the domains. + + Opcode can be one of the following: + :: + + = Update the assignment to match the MBM event. + + Assign a new MBM event without impacting existing assignments. + - Unassign a MBM event from currently assigned events. + + Examples: + Initial group status: + :: + + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_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 assign only total MBM event on domain 0: + :: + + # echo "//0=t" > /sys/fs/resctrl/info/L3_MON/mbm_assign_control + + Assignment status after the update: + :: + + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_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 MBM event on domain 1: + :: + + # echo "/child_default_mon_grp/1-t" > /sys/fs/resctrl/info/L3_MON/mbm_assign_control + + Assignment status after the update: + :: + + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_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 unassign + both local and total MBM events on domain 1: + :: + + # echo "non_default_ctrl_mon_grp/child_non_default_mon_grp/1=_" > + /sys/fs/resctrl/info/L3_MON/mbm_assign_control + + Assignment status after the update: + :: + + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control + 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 MBM event domain 0: + :: + + # echo "//0+l" > /sys/fs/resctrl/info/L3_MON/mbm_assign_control + + Assignment status after the update: + :: + + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_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; + + To update the non default CTRL_MON group non_default_ctrl_mon_grp to unassign all the + MBM events on all the domains: + :: + + # echo "non_default_ctrl_mon_grp//*=_" > /sys/fs/resctrl/info/L3_MON/mbm_assign_control + + Assignment status after the update: + :: + + # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control + non_default_ctrl_mon_grp//0=_;1=_; + 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; + "max_threshold_occupancy": Read/write file provides the largest value (in bytes) at which a previously used LLC_occupancy
arch/x86/kernel/cpu/resctrl/internal.h +10 -0
@@ -62,6 +62,16 @@/* Setting bit 0 in L3_QOS_EXT_CFG enables the ABMC feature. */ #define ABMC_ENABLE_BIT 0 +/* +* Assignment flags for mbm_cntr_assign mode +*/ +enum { +ASSIGN_NONE =0 , +ASSIGN_TOTAL =BIT (QOS_L3_MBM_TOTAL_EVENT_ID ), +ASSIGN_LOCAL =BIT (QOS_L3_MBM_LOCAL_EVENT_ID ), +ASSIGN_INVALID , +}; +/** * cpumask_any_housekeeping() - Choose any CPU in @mask, preferring those that * aren't marked nohz_full
arch/x86/kernel/cpu/resctrl/rdtgroup.c +240 -1
255 lines not on this page · raw message
Signature · 1 line
2.34.1
Reinette Chatre
maintainerRe: [PATCH v10 24/24] x86/resctrl: Introduce interface to modify assignment states of the groups
Hi Babu,
Quoted 1 line · Babu Moger
Introduce the interface to assign MBM events in
mbm_cntr_assignmode.
Seems like something is missing ... there is no mention about what MBM events are assigned "to".
...
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_mbm_assign_control_show(struct kernfs_open_file *of, · line 1228
Quoted 11 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +11
-0+if (assign_state &ASSIGN_LOCAL ) { + ret =rdtgroup_assign_cntr_event (r, rdtgrp, d,QOS_L3_MBM_LOCAL_EVENT_ID ); +if (ret) + goto out_fail; + } + + goto next; + +out_fail: +sprintf (domain, d ?"%ld" :"*" , dom_id); +
The static checker I tried complains that dom_id can be used uninitialized.
Reinette
Re: [PATCH v10 24/24] x86/resctrl: Introduce interface to modify assignment states of the groups
Hi Reinette,
Quoted 7 lines · Reinette Chatre
Hi Babu,
Quoted 1 line · Babu Moger
Introduce the interface to assign MBM events in
mbm_cntr_assignmode.Seems like something is missing ... there is no mention about what MBM events are assigned "to".
Sure. Will add some context.
Quoted 16 lines
...
arch/x86/kernel/cpu/resctrl/rdtgroup.c static int rdtgroup_mbm_assign_control_show(struct kernfs_open_file *of, · line 1228
Quoted 11 lines
arch/x86/kernel/cpu/resctrl/rdtgroup.c +11
-0+if (assign_state &ASSIGN_LOCAL ) { + ret =rdtgroup_assign_cntr_event (r, rdtgrp, d,QOS_L3_MBM_LOCAL_EVENT_ID ); +if (ret) + goto out_fail; + } + + goto next; + +out_fail: +sprintf (domain, d ?"%ld" :"*" , dom_id); +The static checker I tried complains that
dom_idcan be used uninitialized.
Interesting.dom_id can be uninitialized. That is why we have check "d ?"
unsigned long dom_id = 0;
This might help.
Thanks
Babu