linux-kernel - Re: [RFD] resctrl: reassigning a running container's CTRL

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c1ed6c5d-c3fa-fa76-686a-033fe803a74d@arm.com>
Date:   Tue, 25 Oct 2022 16:56:13 +0100
From:   James Morse <james.morse@....com>
To:     Peter Newman <peternewman@...gle.com>,
        Reinette Chatre <reinette.chatre@...el.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 Peter,

On 21/10/2022 11:09, Peter Newman wrote:
> On Thu, Oct 20, 2022 at 9:08 PM Reinette Chatre
> <reinette.chatre@...el.com> wrote:
>>
>> If the expectation is that PARTID counts are very high then how about
>> a solution where multiple PARTIDs are associated with the same CTRL_MON group?
>> A CTRL_MON group presents a resource allocation to user space, CLOSIDs/PARTIDs
>> are not exposed. So using multiple PARTIDs for a resource group (all with the
>> same allocation) seems conceptually ok to me. (Please note, I did not do an
>> audit to see if there are any hidden assumption or look into lifting required
>> to support his.)

> I did propose using PARTIDs to back additional mon_groups a few days ago
> on the other sub-thread with James. My understanding was that it would
> be less trouble if the user opted to do this on their own rather than
> the kernel somehow doing this automatically.
> 
> https://lore.kernel.org/all/835d769b-3662-7be5-dcdd-804cb1f3999a@arm.com/

> So perhaps we can just arrive at some way to inform the user of the
> difference in resources. We may not even need to be able to precisely
> calculate the number of groups we can create, as the logic for us could
> be a simple as:
> 
> 1) If num_closids >= desired job count, just use CTRL_MON groups

> 2) Otherwise, fall back to the proposed mon_group-move approach if
> num_rmids is large enough for the desired job count

> To address the glitchy behavior of moving a PMG to a new PARTID, I found
> that the MPAM spec says explicitly that a PMG is subordinate to a
> PARTID, so I would be fine with James finding a way for the MPAM driver
> to block the rename operation, because it's unable to mix and match
> RMIDs and CLOSIDs the way that RDT can.

I'd like to support moving groups of tasks in a sensible way on MPAM too.

I don't think we should conflate it with 'old counters keep counting' - that should be
exposed as a separate property that influences how user-space sets this stuff up.


Thanks,

James