Re: [PATCH v1 02/31] x86/resctrl: Add a helper to avoid reaching into the arch code resource list

Moger, Babu
2024-04-16T20:44:37Z

Hi Dave,

On 4/16/24 11:15, Dave Martin wrote:
> On Mon, Apr 15, 2024 at 03:28:18PM -0500, Moger, Babu wrote:
>> Hi James/Dave,
>>
>> On 3/21/24 11:50, James Morse wrote:
>>> 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
>>> resctrl_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.
>>
>> Nit.
>> You may want to drop the second half of the statement. We don't have a
>> dummy resource.
>
> I guess not, but MPAM will, although I haven't fully understood the
> logic. See:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/tree/drivers/platform/mpam/mpam_resctrl.c?h=mpam/snapshot/v6.7-rc2
>
> (Search for "dummy".)
>
>
> In any case, the statement above is part of the definition of the new
> interface: the resctrl core code is going to explicitly need to cope
> with a dummy resource being returned, and the arch code is required
> to return a pointer to something and not NULL.
>
> So I would say that it is appropriate (or, at the very least, harmless)
> to keep that statement here?

Ok. fine.
>
>>
>>>
>>> Signed-off-by: James Morse <james.morse@arm.com>
>>> ---
>>> arch/x86/kernel/cpu/resctrl/core.c | 10 +++++++++-
>>> arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 2 +-
>>> arch/x86/kernel/cpu/resctrl/internal.h | 10 ----------
>>> arch/x86/kernel/cpu/resctrl/monitor.c | 8 ++++----
>>> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 15 +++++++--------
>>> include/linux/resctrl.h | 17 +++++++++++++++++
>>> 6 files changed, 38 insertions(+), 24 deletions(-)
>>>
>
> [...]
>
>>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> index 1767c1affa60..45372b6a6215 100644
>>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>
> [...]
>
>>> @@ -2625,10 +2625,10 @@ static void schemata_list_destroy(void)
>>>
>>> static int rdt_get_tree(struct fs_context *fc)
>>> {
>>> + struct rdt_resource *l3 = resctrl_arch_get_resource(RDT_RESOURCE_L3);
>>
>> Its is probably best to keep the resource name as r here to be consistent
>> with other changes.
>>
>>> struct rdt_fs_context *ctx = rdt_fc2context(fc);
>>> unsigned long flags = RFTYPE_CTRL_BASE;
>>> struct rdt_domain *dom;
>>> - struct rdt_resource *r;
>>> int ret;
>>>
>>> cpus_read_lock();
>>> @@ -2701,8 +2701,7 @@ static int rdt_get_tree(struct fs_context *fc)
>>> resctrl_mounted = true;
>>>
>>> if (is_mbm_enabled()) {
>>> - r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl;
>>> - list_for_each_entry(dom, &r->domains, list)
>>> + list_for_each_entry(dom, &l3->domains, list)
>>> mbm_setup_overflow_handler(dom, MBM_OVERFLOW_INTERVAL,
>>> RESCTRL_PICK_ANY_CPU);
>>> }
>>> @@ -3878,7 +3877,7 @@ static int rdtgroup_show_options(struct seq_file *seq, struct kernfs_root *kf)
>
> [...]
>
>> Thanks
>> Babu Moger
>
> [...]
>
> Yes, this does look a bit odd.
>
> This looks like a no-op change to me -- I think that
> resctrl_arch_get_resource() is supposed to be without side-effects,
> so I would have expected this to be a one-line change at the assignment
> to r, with no particular need for renaming r.
>
> Does that make sense to you, or is there some complexity I'm not
> noticing here?

No other complexity.. Just keep the variable name as r.

struct rdt_resource *r = resctrl_arch_get_resource(RDT_RESOURCE_L3);

--
Thanks
Babu Moger