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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d594a7e0-e33e-4311-8079-14dd56f6d309@intel.com>
Date: Tue, 12 Mar 2024 08:13:40 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: <babu.moger@....com>, James Morse <james.morse@....com>, <corbet@....net>,
	<fenghua.yu@...el.com>, <tglx@...utronix.de>, <mingo@...hat.com>,
	<bp@...en8.de>, <dave.hansen@...ux.intel.com>
CC: <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>,
	<peternewman@...gle.com>, <maciej.wieczor-retman@...el.com>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<eranian@...gle.com>
Subject: Re: [PATCH v2 00/17] x86/resctrl : Support AMD Assignable Bandwidth
 Monitoring Counters (ABMC)

Hi Babu,

On 3/11/2024 8:40 AM, Moger, Babu wrote:
> On 2/27/24 17:50, Reinette Chatre wrote:
>> On 2/27/2024 10:12 AM, Moger, Babu wrote:
>>> On 2/26/24 15:20, Reinette Chatre wrote:
>>>> On 2/26/2024 9:59 AM, Moger, Babu wrote:
>>>>> On 2/23/24 16:21, Reinette Chatre wrote:
>>
>>>>>> Apart from the "default behavior" there are two options to consider ...
>>>>>> (a) the "original" behavior(? I do not know what to call it) - this would be
>>>>>>     where user space wants(?) to have the current non-ABMC behavior on an ABMC
>>>>>>     system, where the previous "num_rmids" monitor groups can be created but
>>>>>>     the counters are reset unpredictably ... should this still be supported
>>>>>>     on ABMC systems though?
>>>>>
>>>>> I would say yes. For some reason user(hardware or software issues) is not
>>>>> able to use ABMC mode, they have an option to go back to legacy mode.
>>>>
>>>> I see. Should this perhaps be protected behind the resctrl "debug" mount option?
>>>
>>> The debug option gives wrong impression. It is better to keep the option
>>> open to enable the feature in normal mode.
>>
>> You mentioned that it would only be needed when there are hardware or
>> software issues ... so debug does sound appropriate. Could you please give
>> an example of how debug option gives wrong impression? Why would you want
>> users to keep using "legacy" mode on an ABMC system?
> 
> We may not be able to use "-o debug" option to enable "legacy_mbm".
> With debug option it will always go to legcay mbm even if ABMC is supported.
> 
> For example when ABMC is supported, I cannot mount the resctrl with debug
> option to test ABMC.
> 
> I need to have a way to mount resctrl with ABMC and debug option. I can
> add "-o legacy_mbm" to enable lecacy_mbm.

I do not think it is necessary to add a unique debug option for this.
What if instead the "-o debug" mount option exposes the "original/legacy"
behavior in the control file? This would enable users to only use this
behavior when in "debug" mode while still able to switch between
legacy and assigned counters.

Reinette


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ