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] [thread-next>] [day] [month] [year] [list]

Date: Mon, 20 May 2024 09:25:16 -0500
From: "Moger, Babu" <babu.moger@....com>
To: Peter Newman <peternewman@...gle.com>,
 Reinette Chatre <reinette.chatre@...el.com>
Cc: 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/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.

 --
Thanks
Babu Moger