Re: [PATCH v2 09/10] x86/resctrl: Add arch_has_sparse_bitmaps to explain AMD/Intel CAT difference

[James Morse]

Hi guys,

On 13/05/2020 21:03, Babu Moger wrote:
>> From: Reinette Chatre <reinette.chatre@xxxxxxxxx>
>> On 4/30/2020 10:03 AM, James Morse wrote:
>>> Intel expects the cache bitmap provided by user-space to have on a
>>> single span of 1s, whereas AMD can support bitmaps like 0xf00f.
>>> Arm's MPAM support also allows sparse bitmaps.
>>>
>>> To move resctrl out to /fs/ we need to explain platform differences
>>> like this. Add a resource property arch_has_sparse_bitmaps. Test this
>>> around the 'non-consecutive' test in cbm_validate().
>>>
>>> Merging the validate calls causes AMD top gain the min_cbm_bits test

top -> to

>>> needed for Haswell, but as it always sets this value to 1, it will
>>> never match.
>>>
>>> CC: Babu Moger <Babu.Moger@xxxxxxx>
>>> Signed-off-by: James Morse <james.morse@xxxxxxx>
>>> Reviewed-by: Reinette Chatre <reinette.chatre@xxxxxxxxx>
>>
>> The Intel bits do indeed look good to me but we should check the AMD
>> portion ... I peeked at the AMD spec [1] and found "If an L3_MASK_n
>> register is programmed with all 0âs, that COS will be prevented from
>> allocating any lines in the L3 cache" ... so AMD does allow bitmasks of
>> all 0's (Intel does not).
>>
>> Does MPAM also allow all 0's? Perhaps "arch_has_sparse_bitmaps" can be
>> used to indicate that also?

It does...


> That is right. AMD allows  L3 mask be all 0s.  I will be great if this
> property can be indicated it here. Thanks

Ah, this is a bug I didn't intend to introduce!

Intel has:
|âââââââif (val == 0 || val > r->default_ctrl) {

Whereas AMD:
|âââââââif (val > r->default_ctrl) {


So this empty bitmap is permitted today with resctrl. (and, its another try-it-and-see).

I'll add an 'arch_has_empty_bitmaps', I don't think overloading 'sparse' to mean 'sparse
and empty' is a good idea.


Thanks!

James