|
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7 |
|
| #
823beb31 |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Move get_{mon,ctrl}_domain_from_cpu() to live with their callers
Each of get_{mon,ctrl}_domain_from_cpu() only has one caller.
Once the filesystem code is moved to /fs/, there is no eq
x86/resctrl: Move get_{mon,ctrl}_domain_from_cpu() to live with their callers
Each of get_{mon,ctrl}_domain_from_cpu() only has one caller.
Once the filesystem code is moved to /fs/, there is no equivalent to core.c.
Move these functions to each live next to their caller. This allows them to be made static and the header file entries to be removed.
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Babu Moger <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Shaopeng Tan <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
373af4ec |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Move RFTYPE flags to be managed by resctrl
resctrl_file_fflags_init() is called from the architecture specific code to make the 'thread_throttle_mode' file visible. The architecture spe
x86/resctrl: Move RFTYPE flags to be managed by resctrl
resctrl_file_fflags_init() is called from the architecture specific code to make the 'thread_throttle_mode' file visible. The architecture specific code has already set the membw.throttle_mode in the rdt_resource.
This forces the RFTYPE flags used by resctrl to be exposed to the architecture specific code.
This doesn't need to be specific to the architecture, the throttle_mode can be used by resctrl to determine if the 'thread_throttle_mode' file should be visible. This allows the RFTYPE flags to be private to resctrl.
Add thread_throttle_mode_init(), and use it to call resctrl_file_fflags_init() from resctrl_init(). This avoids publishing an extra function between the architecture and filesystem code.
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Babu Moger <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Shaopeng Tan <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
37bae175 |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Move mba_mbps_default_event init to filesystem code
mba_mbps_default_event is initialised based on whether mbm_local or mbm_total is supported. In the case of both, it is initialised to
x86/resctrl: Move mba_mbps_default_event init to filesystem code
mba_mbps_default_event is initialised based on whether mbm_local or mbm_total is supported. In the case of both, it is initialised to mbm_local. mba_mbps_default_event is initialised in core.c's get_rdt_mon_resources(), while all the readers are in rdtgroup.c.
After this code is split into architecture-specific and filesystem code, get_rdt_mon_resources() remains part of the architecture code, which would mean mba_mbps_default_event has to be exposed by the filesystem code.
Move the initialisation to the filesystem's resctrl_mon_resource_init().
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Babu Moger <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Shaopeng Tan <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
d81826f8 |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Add resctrl_arch_is_evt_configurable() to abstract BMEC
When BMEC is supported the resctrl event can be configured in a number of ways. This depends on architecture support. rdt_get_mon
x86/resctrl: Add resctrl_arch_is_evt_configurable() to abstract BMEC
When BMEC is supported the resctrl event can be configured in a number of ways. This depends on architecture support. rdt_get_mon_l3_config() modifies the struct mon_evt and calls resctrl_file_fflags_init() to create the files that allow the configuration.
Splitting this into separate architecture and filesystem parts would require the struct mon_evt and resctrl_file_fflags_init() to be exposed.
Instead, add resctrl_arch_is_evt_configurable(), and use this from resctrl_mon_resource_init() to initialise struct mon_evt and call resctrl_file_fflags_init().
resctrl_arch_is_evt_configurable() calls rdt_cpu_has() so it doesn't obviously benefit from being inlined. Putting it in core.c will allow rdt_cpu_has() to eventually become static.
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Carl Worth <[email protected]> # arm64 Tested-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
d012b66a |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Move the is_mbm_*_enabled() helpers to asm/resctrl.h
The architecture specific parts of resctrl provide helpers like is_mbm_total_enabled() and is_mbm_local_enabled() to hide accesses t
x86/resctrl: Move the is_mbm_*_enabled() helpers to asm/resctrl.h
The architecture specific parts of resctrl provide helpers like is_mbm_total_enabled() and is_mbm_local_enabled() to hide accesses to the rdt_mon_features bitmap.
Exposing a group of helpers between the architecture and filesystem code is preferable to a single unsigned-long like rdt_mon_features. Helpers can be more readable and have a well defined behaviour, while allowing architectures to hide more complex behaviour.
Once the filesystem parts of resctrl are moved, these existing helpers can no longer live in internal.h. Move them to include/linux/resctrl.h Once these are exposed to the wider kernel, they should have a 'resctrl_arch_' prefix, to fit the rest of the arch<->fs interface.
Move and rename the helpers that touch rdt_mon_features directly. is_mbm_event() and is_mbm_enabled() are only called from rdtgroup.c, so can be moved into that file.
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Babu Moger <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Tested-by: Carl Worth <[email protected]> # arm64 Tested-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
01184272 |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Move monitor exit work to a resctrl exit call
rdt_put_mon_l3_config() is called via the architecture's resctrl_arch_exit() call, and appears to free the rmid_ptrs[] and closid_num_dirty
x86/resctrl: Move monitor exit work to a resctrl exit call
rdt_put_mon_l3_config() is called via the architecture's resctrl_arch_exit() call, and appears to free the rmid_ptrs[] and closid_num_dirty_rmid[] arrays. In reality this code is marked __exit, and is removed by the linker as resctrl can't be built as a module.
To separate the filesystem and architecture parts of resctrl, this free()ing work needs to be triggered by the filesystem, as these structures belong to the filesystem code.
Rename rdt_put_mon_l3_config() to resctrl_mon_resource_exit() and call it from resctrl_exit(). The kfree() is currently dependent on r->mon_capable.
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Carl Worth <[email protected]> # arm64 Tested-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
e3d5138c |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Move rdt_find_domain() to be visible to arch and fs code
rdt_find_domain() finds a domain given a resource and a cache-id. This is used by both the architecture code and the filesystem
x86/resctrl: Move rdt_find_domain() to be visible to arch and fs code
rdt_find_domain() finds a domain given a resource and a cache-id. This is used by both the architecture code and the filesystem code.
After the filesystem code moves to live in /fs/, this helper is either duplicated by all architectures, or needs exposing by the filesystem code.
Add the declaration to the global header file. As it's now globally visible, and has only a handful of callers, swap the 'rdt' for 'resctrl'. Move the function to live with its caller in ctrlmondata.c as the filesystem code will not have anything corresponding to core.c.
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Babu Moger <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Shaopeng Tan <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
8079565d |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Expose resctrl fs's init function to the rest of the kernel
rdtgroup_init() needs exposing to the rest of the kernel so that arch code can call it once it lives in core code. As this is
x86/resctrl: Expose resctrl fs's init function to the rest of the kernel
rdtgroup_init() needs exposing to the rest of the kernel so that arch code can call it once it lives in core code. As this is one of the few functions exposed, rename it to have "resctrl" in the name. The same goes for the exit call.
Rename x86's arch code init functions for RDT to have an arch prefix to make it clear these are part of the architecture code.
Co-developed-by: Dave Martin <[email protected]> Signed-off-by: Dave Martin <[email protected]> Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Carl Worth <[email protected]> # arm64 Tested-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
dbc58f7e |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Generate default_ctrl instead of sharing it
The struct rdt_resource default_ctrl is used by both the architecture code for resetting the hardware controls, and sometimes by the filesyst
x86/resctrl: Generate default_ctrl instead of sharing it
The struct rdt_resource default_ctrl is used by both the architecture code for resetting the hardware controls, and sometimes by the filesystem code as the default value for the schema, unless the bandwidth software controller is in use.
Having the default exposed by the architecture code causes unnecessary duplication for each architecture as the default value must be specified, but can be derived from other schema properties. Now that the maximum bandwidth is explicitly described, resctrl can derive the default value from the schema format and the other resource properties.
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Carl Worth <[email protected]> # arm64 Tested-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
634ebb98 |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Add max_bw to struct resctrl_membw
__rdt_get_mem_config_amd() and __get_mem_config_intel() both use the default_ctrl property as a maximum value. This is because the MBA schema works di
x86/resctrl: Add max_bw to struct resctrl_membw
__rdt_get_mem_config_amd() and __get_mem_config_intel() both use the default_ctrl property as a maximum value. This is because the MBA schema works differently between these platforms. Doing this complicates determining whether the default_ctrl property belongs to the arch code, or can be derived from the schema format.
Deriving the maximum or default value from the schema format would avoid the architecture code having to tell resctrl such obvious things as the maximum percentage is 100, and the maximum bitmap is all ones.
Maximum bandwidth is always going to vary per platform. Add max_bw as a special case. This is currently used for the maximum MBA percentage on Intel platforms, but can be removed from the architecture code if 'percentage' becomes a schema format resctrl supports directly.
This value isn't needed for other schema formats.
This will allow the default_ctrl to be generated from the schema properties when it is needed.
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Carl Worth <[email protected]> # arm64 Tested-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
43312b8e |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Remove data_width and the tabular format
The resctrl architecture code provides a data_width for the controls of each resource. This is used to zero pad all control values in the schema
x86/resctrl: Remove data_width and the tabular format
The resctrl architecture code provides a data_width for the controls of each resource. This is used to zero pad all control values in the schemata file so they appear in columns. The same is done with the resource names to complete the visual effect. e.g.
| SMBA:0=2048 | L3:0=00ff
AMD platforms discover their maximum bandwidth for the MB resource from firmware, but hard-code the data_width to 4. If the maximum bandwidth requires more digits - the tabular format is silently broken. This is also broken when the mba_MBps mount option is used as the field width isn't updated. If new schema are added resctrl will need to be able to determine the maximum width. The benefit of this pretty-printing is questionable.
Instead of handling runtime discovery of the data_width for AMD platforms, remove the feature. These fields are always zero padded so should be harmless to remove if the whole field has been treated as a number. In the above example, this would now look like this:
| SMBA:0=2048 | L3:0=ff
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
bb9343c8 |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Use schema type to determine the schema format string
Resctrl's architecture code gets to specify a format string that is used when printing schema entries. This is expected to be one o
x86/resctrl: Use schema type to determine the schema format string
Resctrl's architecture code gets to specify a format string that is used when printing schema entries. This is expected to be one of two values that the filesystem code supports.
Setting this format string allows the architecture code to change the ABI resctrl presents to user-space.
Instead, use the schema format enum to choose which format string to use.
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Carl Worth <[email protected]> # arm64 Tested-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
c24f5eab |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Use schema type to determine how to parse schema values
Resctrl's architecture code gets to specify a function pointer that is used when parsing schema entries. This is expected to be o
x86/resctrl: Use schema type to determine how to parse schema values
Resctrl's architecture code gets to specify a function pointer that is used when parsing schema entries. This is expected to be one of two helpers from the filesystem code.
Setting this function pointer allows the architecture code to change the ABI resctrl presents to user-space, and forces resctrl to expose these helpers.
Instead, add a schema format enum to choose which schema parser to use. This allows the helpers to be made static and the structs used for passing arguments moved out of shared headers.
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Carl Worth <[email protected]> # arm64 Tested-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
131dab13 |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Remove fflags from struct rdt_resource
The resctrl arch code specifies whether a resource controls a cache or memory using the fflags field. This field is then used by resctrl to determ
x86/resctrl: Remove fflags from struct rdt_resource
The resctrl arch code specifies whether a resource controls a cache or memory using the fflags field. This field is then used by resctrl to determine which files should be exposed in the filesystem.
Allowing the architecture to pick this value means the RFTYPE_ flags have to be in a shared header, and allows an architecture to create a combination that resctrl does not support.
Remove the fflags field, and pick the value based on the resource id.
Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Shaopeng Tan <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
3c021531 |
| 11-Mar-2025 |
James Morse <[email protected]> |
x86/resctrl: Add a helper to avoid reaching into the arch code resource list
Resctrl occasionally wants to know something about a specific resource, in these cases it reaches into the arch code's rd
x86/resctrl: Add a helper to avoid reaching into the arch code resource list
Resctrl occasionally wants to know something about a specific resource, in these cases it reaches into the arch code's rdt_resources_all[] array.
Once the filesystem parts of resctrl are moved to /fs/, this means it will need visibility of the architecture specific struct rdt_hw_resource definition, and the array of all resources. All architectures would also need a r_resctrl member in this struct.
Instead, abstract this via a helper to allow architectures to do different things here. Move the level enum to the resctrl header and add a helper to retrieve the struct rdt_resource by 'rid'.
resctrl_arch_get_resource() should not return NULL for any value in the enum, it may instead return a dummy resource that is !alloc_enabled && !mon_enabled.
Co-developed-by: Dave Martin <[email protected]> Signed-off-by: Dave Martin <[email protected]> Signed-off-by: James Morse <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Shaopeng Tan <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Reviewed-by: Tony Luck <[email protected]> Reviewed-by: Fenghua Yu <[email protected]> Reviewed-by: Babu Moger <[email protected]> Tested-by: Peter Newman <[email protected]> Tested-by: Carl Worth <[email protected]> # arm64 Tested-by: Shaopeng Tan <[email protected]> Tested-by: Amit Singh Tomar <[email protected]> # arm64 Tested-by: Shanker Donthineni <[email protected]> # arm64 Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2 |
|
| #
141cb5c4 |
| 06-Dec-2024 |
Tony Luck <[email protected]> |
x86/resctrl: Make mba_sc use total bandwidth if local is not supported
The default input measurement to the mba_sc feedback loop for memory bandwidth control when the user mounts with the "mba_MBps"
x86/resctrl: Make mba_sc use total bandwidth if local is not supported
The default input measurement to the mba_sc feedback loop for memory bandwidth control when the user mounts with the "mba_MBps" option is the local bandwidth event. But some systems may not support a local bandwidth event.
When local bandwidth event is not supported, check for support of total bandwidth and use that instead.
Relax the mount option check to allow use of the "mba_MBps" option for systems when only total bandwidth monitoring is supported. Also update the error message.
Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
3b49c37a |
| 06-Dec-2024 |
Tony Luck <[email protected]> |
x86/resctrl: Prepare for per-CTRL_MON group mba_MBps control
Resctrl uses local memory bandwidth event as input to the feedback loop when the mba_MBps mount option is used. This means that this moun
x86/resctrl: Prepare for per-CTRL_MON group mba_MBps control
Resctrl uses local memory bandwidth event as input to the feedback loop when the mba_MBps mount option is used. This means that this mount option cannot be used on systems that only support monitoring of total bandwidth.
Prepare to allow users to choose the input event independently for each CTRL_MON group by adding a global variable "mba_mbps_default_event" used to set the default event for each CTRL_MON group, and a new field "mba_mbps_event" in struct rdtgroup to track which event is used for each CTRL_MON group.
Notes:
1) Both of these are only used when the user mounts the filesystem with the "mba_MBps" option. 2) Only check for support of local bandwidth event when initializing mba_mbps_default_event. Support for total bandwidth event can be added after other routines in resctrl have been updated to handle total bandwidth event.
[ bp: Move mba_mbps_default_event extern into the arch header. ]
Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
2937f9c3 |
| 06-Dec-2024 |
Babu Moger <[email protected]> |
x86/resctrl: Introduce resctrl_file_fflags_init() to initialize fflags
thread_throttle_mode_init() and mbm_config_rftype_init() both initialize fflags for resctrl files.
Adding new files will invol
x86/resctrl: Introduce resctrl_file_fflags_init() to initialize fflags
thread_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().
[ Tony: Drop __init attribute so resctrl_file_fflags_init() can be used at run time. ]
Signed-off-by: Babu Moger <[email protected]> Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1 |
|
| #
d5fd042b |
| 17-Sep-2024 |
Nathan Chancellor <[email protected]> |
x86/resctrl: Annotate get_mem_config() functions as __init
After a recent LLVM change [1] that deduces __cold on functions that only call cold code (such as __init functions), there is a section mis
x86/resctrl: Annotate get_mem_config() functions as __init
After a recent LLVM change [1] that deduces __cold on functions that only call cold code (such as __init functions), there is a section mismatch warning from __get_mem_config_intel(), which got moved to .text.unlikely. as a result of that optimization:
WARNING: modpost: vmlinux: section mismatch in reference: \ __get_mem_config_intel+0x77 (section: .text.unlikely.) -> thread_throttle_mode_init (section: .init.text)
Mark __get_mem_config_intel() as __init as well since it is only called from __init code, which clears up the warning.
While __rdt_get_mem_config_amd() does not exhibit a warning because it does not call any __init code, it is a similar function that is only called from __init code like __get_mem_config_intel(), so mark it __init as well to keep the code symmetrical.
CONFIG_SECTION_MISMATCH_WARN_ONLY=n would turn this into a fatal error.
Fixes: 05b93417ce5b ("x86/intel_rdt/mba: Add primary support for Memory Bandwidth Allocation (MBA)") Fixes: 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature") Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Cc: <[email protected]> Link: https://github.com/llvm/llvm-project/commit/6b11573b8c5e3d36beee099dbe7347c2a007bf53 [1] Link: https://lore.kernel.org/r/20240917-x86-restctrl-get_mem_config_intel-init-v3-1-10d521256284@kernel.org
show more ...
|
|
Revision tags: v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5 |
|
| #
a547a588 |
| 22-Aug-2024 |
Peter Newman <[email protected]> |
x86/resctrl: Fix arch_mbm_* array overrun on SNC
When using resctrl on systems with Sub-NUMA Clustering enabled, monitoring groups may be allocated RMID values which would overrun the arch_mbm_{loca
x86/resctrl: Fix arch_mbm_* array overrun on SNC
When using resctrl on systems with Sub-NUMA Clustering enabled, monitoring groups may be allocated RMID values which would overrun the arch_mbm_{local,total} arrays.
This is due to inconsistencies in whether the SNC-adjusted num_rmid value or the unadjusted value in resctrl_arch_system_num_rmid_idx() is used. The num_rmid value for the L3 resource is currently:
resctrl_arch_system_num_rmid_idx() / snc_nodes_per_l3_cache
As a simple fix, make resctrl_arch_system_num_rmid_idx() return the SNC-adjusted, L3 num_rmid value on x86.
Fixes: e13db55b5a0d ("x86/resctrl: Introduce snc_nodes_per_l3_cache") Signed-off-by: Peter Newman <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7 |
|
| #
21b362cc |
| 02-Jul-2024 |
Tony Luck <[email protected]> |
x86/resctrl: Enable shared RMID mode on Sub-NUMA Cluster (SNC) systems
Hardware has two RMID configuration options for SNC systems. The default mode divides RMID counters between SNC nodes. E.g. wit
x86/resctrl: Enable shared RMID mode on Sub-NUMA Cluster (SNC) systems
Hardware has two RMID configuration options for SNC systems. The default mode divides RMID counters between SNC nodes. E.g. with 200 RMIDs and two SNC nodes per L3 cache RMIDs 0..99 are used on node 0, and 100..199 on node 1. This isn't compatible with Linux resctrl usage. On this example system a process using RMID 5 would only update monitor counters while running on SNC node 0.
The other mode is "RMID Sharing Mode". This is enabled by clearing bit 0 of the RMID_SNC_CONFIG (0xCA0) model specific register. In this mode the number of logical RMIDs is the number of physical RMIDs (from CPUID leaf 0xF) divided by the number of SNC nodes per L3 cache instance. A process can use the same RMID across different SNC nodes.
See the "Intel Resource Director Technology Architecture Specification" for additional details.
When SNC is enabled, update the MSR when a monitor domain is marked online. Technically this is overkill. It only needs to be done once per L3 cache instance rather than per SNC domain. But there is no harm in doing it more than once, and this is not in a critical path.
Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
|
Revision tags: v6.10-rc6 |
|
| #
328ea688 |
| 28-Jun-2024 |
Tony Luck <[email protected]> |
x86/resctrl: Prepare for new Sub-NUMA Cluster (SNC) monitor files
When SNC is enabled, monitoring data is collected at the SNC node granularity, but must be reported at L3-cache granularity for back
x86/resctrl: Prepare for new Sub-NUMA Cluster (SNC) monitor files
When SNC is enabled, monitoring data is collected at the SNC node granularity, but must be reported at L3-cache granularity for backwards compatibility in addition to reporting at the node level.
Add a "ci" field to the rdt_mon_domain structure to save the cache information about the enclosing L3 cache for the domain. This provides:
1) The cache id which is needed to compose the name of the legacy monitoring directory, and to determine which domains should be summed to provide L3-scoped data.
2) The shared_cpu_map which is needed to determine which CPUs can be used to read the RMID counters with the MSR interface.
This is the first step to an eventual goal of monitor reporting files like this (for a system with two SNC nodes per L3):
$ cd /sys/fs/resctrl/mon_data $ tree mon_L3_00 mon_L3_00 <- 00 here is L3 cache id ├── llc_occupancy \ These files provide legacy support ├── mbm_local_bytes > for non-SNC aware monitor apps ├── mbm_total_bytes / that expect data at L3 cache level ├── mon_sub_L3_00 <- 00 here is SNC node id │ ├── llc_occupancy \ These files are finer grained │ ├── mbm_local_bytes > data from each SNC node │ └── mbm_total_bytes / └── mon_sub_L3_01 ├── llc_occupancy \ ├── mbm_local_bytes > As above, but for node 1. └── mbm_total_bytes /
[ bp: Massage commit message. ]
Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
1a171608 |
| 28-Jun-2024 |
Tony Luck <[email protected]> |
x86/resctrl: Add node-scope to the options for feature scope
Currently supported resctrl features are all domain scoped the same as the scope of the L2 or L3 caches.
Add RESCTRL_L3_NODE as a new op
x86/resctrl: Add node-scope to the options for feature scope
Currently supported resctrl features are all domain scoped the same as the scope of the L2 or L3 caches.
Add RESCTRL_L3_NODE as a new option for features that are scoped at the same granularity as NUMA nodes. This is needed for Intel's Sub-NUMA Cluster (SNC) feature where monitoring features are divided between nodes that share an L3 cache.
Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
cae2bcb6 |
| 28-Jun-2024 |
Tony Luck <[email protected]> |
x86/resctrl: Split the rdt_domain and rdt_hw_domain structures
The same rdt_domain structure is used for both control and monitor functions. But this results in wasted memory as some of the fields a
x86/resctrl: Split the rdt_domain and rdt_hw_domain structures
The same rdt_domain structure is used for both control and monitor functions. But this results in wasted memory as some of the fields are only used by control functions, while most are only used for monitor functions.
Split into separate rdt_ctrl_domain and rdt_mon_domain structures with just the fields required for control and monitoring respectively.
Similar split of the rdt_hw_domain structure into rdt_hw_ctrl_domain and rdt_hw_mon_domain.
Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| #
cd84f72b |
| 28-Jun-2024 |
Tony Luck <[email protected]> |
x86/resctrl: Prepare for different scope for control/monitor operations
Resctrl assumes that control and monitor operations on a resource are performed at the same scope.
Prepare for systems that u
x86/resctrl: Prepare for different scope for control/monitor operations
Resctrl assumes that control and monitor operations on a resource are performed at the same scope.
Prepare for systems that use different scope (specifically Intel needs to split the RDT_RESOURCE_L3 resource to use L3 scope for cache control and NODE scope for cache occupancy and memory bandwidth monitoring).
Create separate domain lists for control and monitor operations.
Note that errors during initialization of either control or monitor functions on a domain would previously result in that domain being excluded from both control and monitor operations. Now the domains are allocated independently it is no longer required to disable both control and monitor operations if either fail.
Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Tested-by: Babu Moger <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|