From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A3EEEC433FE for ; Thu, 3 Nov 2022 17:08:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232166AbiKCRIQ (ORCPT ); Thu, 3 Nov 2022 13:08:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231817AbiKCRHS (ORCPT ); Thu, 3 Nov 2022 13:07:18 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5EF9111C09 for ; Thu, 3 Nov 2022 10:06:38 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 64B9F1FB; Thu, 3 Nov 2022 10:06:44 -0700 (PDT) Received: from [10.1.197.38] (eglon.cambridge.arm.com [10.1.197.38]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5A2AE3F5A1; Thu, 3 Nov 2022 10:06:36 -0700 (PDT) Message-ID: <0c6fdf46-284c-6ed1-db44-a1e93037afe3@arm.com> Date: Thu, 3 Nov 2022 17:06:24 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [RFD] resctrl: reassigning a running container's CTRL_MON group Content-Language: en-GB To: Peter Newman Cc: Reinette Chatre , Tony Luck , "Yu, Fenghua" , "Eranian, Stephane" , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Babu Moger , Gaurang Upasani References: <81a7b4f6-fbb5-380e-532d-f2c1fc49b515@intel.com> <7b09fb62-e61a-65b9-a71e-ab725f527ded@intel.com> From: James Morse In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, On 26/10/2022 10:36, Peter Newman wrote: > On Tue, Oct 25, 2022 at 5:56 PM James Morse 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