Message-ID: <d412f235-c2c8-28bc-4b2e-fbf353cbf192@intel.com>
Date:   Mon, 14 Nov 2022 10:02:54 -0800
From:   Reinette Chatre <reinette.chatre@...el.com>
To:     James Morse <james.morse@....com>,
        Peter Newman <peternewman@...gle.com>
CC:     Tony Luck <tony.luck@...el.com>,
        "Yu, Fenghua" <fenghua.yu@...el.com>,
        "Eranian, Stephane" <eranian@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Babu Moger" <Babu.Moger@....com>,
        Gaurang Upasani <gupasani@...gle.com>
Subject: Re: [RFD] resctrl: reassigning a running container's CTRL_MON group

Hi James and Peter,

On 11/11/2022 10:38 AM, James Morse wrote:
> On 09/11/2022 19:11, Reinette Chatre wrote:
>> On 11/9/2022 1:50 AM, Peter Newman wrote:
>>> On Tue, Nov 8, 2022 at 10:28 PM Reinette Chatre
>>> <reinette.chatre@...el.com> wrote:
>>>> On 11/3/2022 10:06 AM, James Morse wrote:
>>>>> That is true. MPAM has an additional headache here as it needs to allocate a monitor in
>>>>> order to read the counters. If there are enough monitors for each CLOSID*RMID to have one,
>>>>> then MPAM can export the counter files in the same way RDT does.
>>>>>
>>>>> While there are systems that have enough monitors, I don't think this is going to be the
>>>>> norm. To allow systems that don't have a surfeit of monitors to use the counters, I plan
>>>>> to export the values from resctrl_arch_rmid_read() via perf. (but only for bandwidth counters)
>>>>
>>>> This sounds related to the way monitoring was done in earlier kernels. This was
>>>> long before I become involved with this work. Unfortunately I am not familiar with
>>>> all the history involved that ended in it being removed from the kernel. Looks like
>>>> this was around v4.6, here is a sample commit that may help point to what was done:
>>>
>>> Sort of related, this is a problem we have to work around on AMD
>>> implementations that I will be sharing a patch for soon.
>>>
>>> Note the second paragraph at the top of page 13:
>>>
>>> https://developer.amd.com/wp-content/resources/56375_1.00.pdf

Please note that there is a more recent version, v1.03, of the spec
available: 
https://www.amd.com/en/support/tech-docs/amd64-technology-platform-quality-service-extensions

> 
>>> AMD QoS often provides less counters than RMIDs, but the architecture
>>> promises there will be at least as many counters in a QoS domain as
>>> CPUs.
> 
> How do you know which RMIDs the hardware is tracking?
> 
> This reads like the counters are unreliable unless the task is running, and even then they
> might lose values when the task is switched out.
> 
> 
>>> Using this we can permanently pin RMIDs to CPUs and read the
>>> counters on every task switch to implement MBM RMIDs in software.
> 
>>> This has the caveats that evictions while one task is running could have
>>> resulted from a previous task on the current CPU, but will be counted
>>> against the new task's software-RMID, and that CMT doesn't work.
> 
> (Sounds like the best thing to do in a bad situation)
> 
> 
>>> I will propose making this available as a mount option for cloud container
>>> use cases which need to monitor a large number of tasks on B/W counter-poor
>>> systems, and of course don't need CMT.
> 
> Why does it need to be a mount option?
> 
> If this is the only way of using the counters on this platform, then the skid from the
> counters is just a property of the platform. It can be advertised to user-space via some
> file in 'info'.

It is not clear to me from the snippet in the spec if these platforms can easily
be identified. It sounds like the only way these platforms are different is that
they more often return "unavailable" when attempting to read a counter. If this
is the case, then knowing when to change the mechanism of counting does not seem
like a simple check.

> 
> Architecture specific mount options are a bad idea, platform specific ones are even worse!
> 
> 
>>>> [...]
>>>>
>>>>> I think the solution to all this is:
>>>>>  * Add rename support to move a monitor group between two control groups.
>>>>>  ** On x86, this is guaranteed to preserve the RMID, so the destination counter continues
>>>>> unaffected.
>>>>>  ** On arm64, the PARTID is also relevant to the monitors, so the old counters will
>>>>> continue to count.
>>>>
>>>> This looks like the solution to me also.
>>>>
>>>> The details of the arm64 support is not clear to me though. The destination
>>>> group may not have enough PMG to host the new group so failures need to be
>>>> handled. As you mention also, the old counters will continue to count.
>>>> I assume that you mean the hardware will still have a record of the occupancy
>>>> and that needs some time to dissipate? I assume this would fall under the
>>>> limbo handling so in some scenarios (for example the just moved monitor
>>>> group used the last PMG) it may take some time for the source control
>>>> group to allow a new monitor group? The new counters will also not
>>>> reflect the task's history.
>>>>
>>>> Moving an arm64  monitor group may thus have a few surprises for user
>>>> space while sounding complex to support. Would adding all this additional
>>>> support be worth it if the guidance to user space is to instead create many
>>>> control groups in such a control-group-rich environment?
>>>>
>>>>> Whether this old counters keep counting needs exposing to user-space so that it is aware.
>>>>
>>>> Could you please elaborate? Do old counters not always keep counting?
>>>
>>> Based on this, is it even worth it to allocate PMGs given that the
>>> systems James has seen so far only have a single PMG bit? All this will
>>> get us is the ability to create a single child mon_group in each control
>>> group. This seems too limiting for the feature to be useful.
> 
> It lets you exclude tasks, or only monitor a specific task. Its evidently enough for the
> markets those parts are manufactured for!
> 
> 
>> I'll mostly defer to James here. From my side I do not see motivation to
>> not support environments in which only one monitor group can be created.
>> My concern was the additional complexity involved to support
>> "mv" of monitor groups in such a constrained environment but I understand
>> from James (re. https://lore.kernel.org/lkml/8325a442-92c1-4170-1862-3bc891a8d6af@arm.com/)
>> that it is worth it.
> 
> I'm strongly against having parts of this interface work differently on different
> architectures or platforms. If it does, we may as well have completely different
> interfaces as user-space has to be architecture/platform aware.

The architectures respond differently though and software cannot hide that. For example,
resctrl can support "mv" for all but from what I understand there is no way to hide
different architecture behaviors. Users will notice that sometimes the counters
keep counting and sometimes they don't.

> Its perfectly possible for the filesystem bits of resctrl to support renaming monitor
> groups between control groups, with only a minimum of 'swap the RMID' that can be skipped
> if an architecture doesn't support it.

right

> 
> 'mv' should be supported on all architectures/platforms, and we should expose enough
> information to user-space for it to work out if its going to build a control/monitor group
> structure that relies on that.

Yes, I agree about supporting "mv". My concern is about the additional
complexity of attempting to have it behave ideally (eg. counters keep counting) while
users are not expected to use/rely on the complexity but instead use the additional exposed
information to build its control/monitor groups differently.   

Reinette

Powered by blists - more mailing lists