Hi Babu,
On 5/7/2024 9:28 AM, Moger, Babu wrote:
> On 5/3/24 18:28, Reinette Chatre wrote:
>> On 3/28/2024 6:06 PM, Babu Moger wrote:
>>> diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
>>> index 735b449039c1..48d1957ea5a3 100644
>>> --- a/arch/x86/kernel/cpu/resctrl/monitor.c
>>> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c
>>> @@ -1058,8 +1058,10 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *r)
>>> RFTYPE_MON_INFO | RFTYPE_RES_CACHE);
>>> }
>>>
>>> - if (resctrl_arch_has_abmc(r))
>>> + if (resctrl_arch_has_abmc(r)) {
>>> r->mbm_assign_capable = ABMC_ASSIGN;
>>> + resctrl_file_fflags_init("mbm_assign", RFTYPE_MON_INFO);
>>
>> I think this will need some more thought when considering the fs/arch split.
>> The architecture can be expected to set r->mbm_assign_capable as above but
>> having the architecture meddle with the fs flags does not seem like the right
>> thing to do. I think that RFTYPE_MON_INFO may not be accessible to arch code
>> anyway.
>
> It is accessible to both arch and fs code per latest code.
> https://lore.kernel.org/lkml/20240426150904.8854-33-Dave.Martin@xxxxxxx/
v2 of MPAM was posted without completing discussion of v1 nor addressing
all feedback.
Please read discussions surrounding #3 and #30 of v1. Note in particular suggestion
in [1] to keep RF flags internal to FS code.
If MPAM chooses to submit new versions without completing discussions then
I have no problem letting ABMC proceed to build on what is resctrl at this time
and adding this to the pile of things MPAM needs to address during fs/arch split.
Reinette
[1] https://lore.kernel.org/lkml/b2595743-c7dc-4946-884f-ff159bc4865e@xxxxxxxxx/
