Re: [RFD] resctrl: reassigning a running container's CTRL_MON group

[James Morse <james.morse@arm.com>]

Hi Peter,

On 26/10/2022 10:36, Peter Newman wrote:
> On Tue, Oct 25, 2022 at 5:56 PM James Morse <james.morse@arm.com> wrote:
>> This would work when systems are built to look like RDT, but MPAM has other control types
>> where this would have interesting behaviours.
>>
>> 'CPOR' is equivalent to CBM as they are both a bitmap of portions. MPAM also has 'CMAX'
>> where a fraction of the cache is specified. If you create two control groups with
>> different PARTIDs but the same configuration, their two 50%s of the cache could become
>> 100%. CPOR can be used like this, CMAX can't.

> I thought we only allocated caches with CBMs and memory bandwidth with
> percentages.

Those are the existing schema, yes.


> I don't see how CMAX could be used when implementing resctrl's CAT
> resources. Percentage
> configurations are only used for MBA in resctrl today.

The problem is if you say "CLOSID/PARTID are random, its the configuration that matters",
you've broken all the control types where the regulation is happening based on the PARTID
and the configuration, not the configuration alone.

If you do this, you can't ever have schema that use those configuration schemes.
There is hardware out there that supports these schemes.


>> Even when the controls behave in the same way, a different PARTID with the same control
>> values could be regulated differently, resulting in weirdness.
> 
> Can you provide further examples?

CMAX, MBW_MIN and MBW_MAX: You can have 50%, and I can have 50%. Your secret clones which
have different PARTID and a copy of your configuration also get 50%. As far as the
hardware is concerned, we're trying to play with more than 100% of the resource.

I don't know what the memory controller people are building, but naively I think the MBW
MIN/MAX stuff is a more natural fit that a bandwidth bitmap.


You couldn't ever add new configuration schemes that are based on a fraction or percentage
of the resource.



Thanks,

James