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: <CALPaoChgi9Z8J7sca_YRHveBW9NzB=PPC1Yp01S=TGiJLBxkQw@mail.gmail.com>
Date:   Fri, 21 Oct 2022 12:09:32 +0200
From:   Peter Newman <peternewman@...gle.com>
To:     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>,
        James Morse <james.morse@....com>,
        Babu Moger <Babu.Moger@....com>,
        Gaurang Upasani <gupasani@...gle.com>
Subject: Re: [RFD] resctrl: reassigning a running container's CTRL_MON group

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.

-Peter