Re: [PATCH v1 09/20] x86/resctrl: Abstract and use supports_mba_mbps()

[James Morse]

Hi Reinette,

On 01/09/2021 22:27, Reinette Chatre wrote:
> On 7/29/2021 3:35 PM, James Morse wrote:
>> To determine whether the mba_mbps option to resctrl should be supported,
> 
> mba_mbps -> mba_MBps
> 
>> resctrl tests the boot cpus' x86_vendor.
> 
> CPU
> 
>>
>> This isn't portable, and needs abstracting behind a helper so this check
>> can be part of the filesystem code that moves to /fs/.

>> Re-use the tests set_mba_sc() does to determine if the mba_sc is supported
>> on this system. An 'alloc_capable' test is added so that this property
>> isn't implied by 'linear'.

> Why can linear not imply alloc_capable? It is a property of a MBA resource so if it is set
> then it has to be a MBA resource.

mba_sc depends on controls and monitors. It checks for monitors with is_mbm_enabled(), and
assumes that the delay_linear property being true means the control feature must exist. I
think this is fragile.

For MPAM, delay_linear is always true. Any way of controlling the bandwidth has this
property. Its very likely to be set statically in the struct, regardless of whether the
controls exist. alloc_capable seems to mean 'controls exist'.

This is to avoid an annoying bug where supports_mba_mbps() reports true, but the controls
aren't available. Or equally annoying, for the arch code to set/clear that flag in
addition to alloc_capable.

I'll add some verbage about MPAM to the commit message.



Thanks,

James