linux-kernel - Re: [RFC PATCH v3 00/17] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <dda69695-0de4-4d0c-936a-128c6c1948f0@amd.com>
Date: Mon, 20 May 2024 13:03:23 -0500
From: "Moger, Babu" <babu.moger@....com>
To: Peter Newman <peternewman@...gle.com>
Cc: Reinette Chatre <reinette.chatre@...el.com>, corbet@....net,
 fenghua.yu@...el.com, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
 paulmck@...nel.org, rdunlap@...radead.org, tj@...nel.org,
 peterz@...radead.org, yanjiewtw@...il.com, kim.phillips@....com,
 lukas.bulwahn@...il.com, seanjc@...gle.com, jmattson@...gle.com,
 leitao@...ian.org, jpoimboe@...nel.org, rick.p.edgecombe@...el.com,
 kirill.shutemov@...ux.intel.com, jithu.joseph@...el.com,
 kai.huang@...el.com, kan.liang@...ux.intel.com,
 daniel.sneddon@...ux.intel.com, pbonzini@...hat.com, sandipan.das@....com,
 ilpo.jarvinen@...ux.intel.com, maciej.wieczor-retman@...el.com,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, eranian@...gle.com,
 james.morse@....com
Subject: Re: [RFC PATCH v3 00/17] x86/resctrl : Support AMD Assignable
 Bandwidth Monitoring Counters (ABMC)

Hi Peter,

On 5/20/24 11:00, Peter Newman wrote:
> Hi Babu,
> 
> On Mon, May 20, 2024 at 7:25 AM Moger, Babu <babu.moger@....com> wrote:
>>
>> Hi Peter,
>>
>> On 5/17/24 16:51, Peter Newman wrote:
>>> Hi Reinette, Babu,
>>>
>>> On Fri, May 3, 2024 at 2:15 PM Reinette Chatre
>>> <reinette.chatre@...el.com> wrote:
>>>>
>>>> Hi Peter,
>>>>
>>>> On 5/3/2024 2:00 PM, Peter Newman wrote:
>>>>> Hi Babu,
>>>>>
>>>>> On Fri, May 3, 2024 at 1:44 PM Moger, Babu <bmoger@....com> wrote:
>>>>>>
>>>>>> Hi Peter,
>>>>>>
>>>>>> On 5/2/2024 7:57 PM, Peter Newman wrote:
>>>>>>> Hi Reinette,
>>>>>>>
>>>>>>> On Thu, May 2, 2024 at 4:21 PM Reinette Chatre
>>>>>>>> I do think ABMC should be enabled by default when available and it looks
>>>>>>>> to be what this series aims to do [1]. The way I reason about this is
>>>>>>>> that legacy user space gets more reliable monitoring behavior without
>>>>>>>> needing to change behavior.
>>>>>>>
>>>>>>> I don't like that for a monitor assignment-aware user, following the
>>>>>>> creation of new monitoring groups, there will be less monitors
>>>>>>> available for assignment. If the user wants precise control over where
>>>>>>> monitors are allocated, they would need to manually unassign the
>>>>>>> automatically-assigned monitor after creating new groups.
>>>>>>>
>>>>>>> It's an annoyance, but I'm not sure if it would break any realistic
>>>>>>> usage model. Maybe if the monitoring agent operates independently of
>>>>>>
>>>>>> Yes. Its annoyance.
>>>>>>
>>>>>> But if you think about it, normal users don't create too many groups.
>>>>>> They wont have to worry about assign/unassign headache if we enable
>>>>>> monitor assignment automatically. Also there is pqos tool which uses
>>>>>> this interface. It does not have to know about assign/unassign stuff.
>>>>>
>>>>> Thinking about this again, I don't think it's much of a concern
>>>>> because the automatic assignment on mongroup creation behavior can be
>>>>> trivially disabled using a boolean flag.
>>>>
>>>> This could be a config option.
>>>
>>> I'd like to work out the details of this option.
>>>
>>> info/L3_MON/mbm_assign_on_mkdir?
>>>
>>> boolean (parsed with kstrtobool()), defaulting to true?
>>
>> I am thinking is not a big concern. We only have limited (32) counters.
>> Automatic monitor assignment works only for first 16 groups(2 counters for
>> each group). When the counters are exhausted auto assignment does not
>> work. In your case(with more than 16 groups) the auto assignment does not
>> work. I feel having a config option is really not necessary.
> 
> I'm not sure I follow the argument you're trying to make because it
> doesn't sound like an argument against adding a config option. What
> exactly do you mean by "work" vs "not work"?
> 
> Also it doesn't address my original concern about needing to manually
> (and non-atomically) undo the auto assignment in order to account for
> where the monitors are assigned or ensure that creating a new
> monitoring group will succeed.
> 

Sorry for the confusion.

Auto monitor assignment works only for small number of groups(15 or less).

After that point user can create more groups. But auto assignment will not
work because the hw counters are all exhausted. You need to manually
unassign a counter from another group and use that counter for new assignment.

I assume that you are dealing with more than 16 groups. In that case, you
have to manually assign/unassign anyways.

Having a config option "info/L3_MON/mbm_assign_on_mkdir" will not be much
helpful for you.

-- 
Thanks
Babu Moger