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: Fri, 17 May 2024 14:51:28 -0700
From: Peter Newman <peternewman@...gle.com>
To: Reinette Chatre <reinette.chatre@...el.com>
Cc: babu.moger@....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 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?

-Peter