Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <37c2371c-11e6-a2ef-059a-1a0ba08c2f67@intel.com>
Date:   Fri, 31 Mar 2023 16:21:12 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.9.1
Subject: Re: [PATCH v3 06/19] x86/resctrl: Allow the allocator to check if a
 CLOSID can allocate clean RMID
Content-Language: en-US
To:     James Morse <james.morse@arm.com>, <x86@kernel.org>,
        <linux-kernel@vger.kernel.org>
CC:     Fenghua Yu <fenghua.yu@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        H Peter Anvin <hpa@zytor.com>,
        Babu Moger <Babu.Moger@amd.com>,
        <shameerali.kolothum.thodi@huawei.com>,
        D Scott Phillips OS <scott@os.amperecomputing.com>,
        <carl@os.amperecomputing.com>, <lcherian@marvell.com>,
        <bobo.shaobowang@huawei.com>, <tan.shaopeng@fujitsu.com>,
        <xingxin.hx@openanolis.org>, <baolin.wang@linux.alibaba.com>,
        Jamie Iles <quic_jiles@quicinc.com>,
        Xin Hao <xhao@linux.alibaba.com>, <peternewman@google.com>
References: <20230320172620.18254-1-james.morse@arm.com>
 <20230320172620.18254-7-james.morse@arm.com>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <20230320172620.18254-7-james.morse@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TUJKOHBTV3Jtb0x1alVvdWRJOHdVWVNLaDk3eVpUZDRGVmlaYVUxZXBURE5Q?=
 =?utf-8?B?Y21hczRkL2Y2L29aRlNwUVJkVmVYUkdhTmNKaUpYbm42TzZnTmY0dEpNT2xv?=
 =?utf-8?B?d3dXa2RZelU2SjY2ckFaS2VmNnJyazh0SWx6d3R5SEd5azRCVFBRWDdwU2g2?=
 =?utf-8?B?bWJlb2RMOUlpOTV0Qm1zbkVVUEx6dkplN1lMMW5NT05uQk53YTFSbHhCUmJr?=
 =?utf-8?B?dDR5d1A5bUMwNHNxS25xNTZMRU9lMjh4ZXFUbWZFTkZRUlh3Vng5VGM4USt0?=
 =?utf-8?B?YkpmQlFwb0dqTzJibWNWZjFmQmd2azJ2M2Q0Q3M2UEwvUE1aQnNJcVl4STJH?=
 =?utf-8?B?WVlYZkw4bzhHOW9RL0hiUnI0akJoQ1Y0elJjVCtUWDVrNUhiUDJYUXIwRkVx?=
 =?utf-8?B?dk55RlFQWktGcW9ZZllsRW55ZEl4VzNvUnAzRVdDY2FVQ3FQcEYwV1hscXJM?=
 =?utf-8?B?SVZBeldMYXJCeGpsT0tTN0RxcW5STEk1bnc1M3MyU1V2N1NHUXpBZ1Z0YS9k?=
 =?utf-8?B?TWQ1cWljL0szemVadVh2K2tBQk5RSXFnWnNEVjgzT2FtUDY0MFIrYnNwRXJG?=
 =?utf-8?B?SFpjdHU0NUw4eWZjWDZncW8rcTIyQVB0YkVyaVlWZTFkS3pXcWgvYjFOUjhD?=
 =?utf-8?B?SWprZ1g4U2FOWlpjTzhwODVkS0FEWithY1c2S3dMc1pNRkpQb0hZY2ZXUDBC?=
 =?utf-8?B?Zi94RG5LRjJ3UTJyMFc1RCtadzFjUTBKM0NJY1RrWndNVTluTGlTeDVKYXdY?=
 =?utf-8?B?aXhSdTBuTHhQcUQzUithYVZZdy9IMUhPZ0E3aE5IYXFNQ0NQZFg4YzJSQmN4?=
 =?utf-8?B?TS9OZ09ZUTVvLzVybDFPZ3M2NnM1QlZFL1QvREFiTWdZZmdlazJhaFFkMks0?=
 =?utf-8?B?ajhvVDN5eml1M1p3UVcyVjhDb1dXYkFEWDByZ2htTUFsVE01cmVGRDFEbTNl?=
 =?utf-8?B?U0U4bGIzM3NtTmNHRUhBLzBoaEorc1I4bElXcHQ1ZTBIeTRHQTRMQjl1ZGdB?=
 =?utf-8?B?a3R3OEVKNHJOK0Fxb3dWQy9vK1EzWGxVRDhQdktGbXh5czZ5cEpIWDNpTGVU?=
 =?utf-8?B?OWVkZlZyMU1FY2dZckhNT3Z4M2xqSVc5MWxkcHc1QWZqOUY2RTdwQ3Q3SXBs?=
 =?utf-8?B?Wk5PWTJhMGJtUE4rOGFBWVpqcVRSNVRJaTNGOWRhOExVMlRYM2VDZW1GdnBN?=
 =?utf-8?B?TDR1dVVma3AwN0ZoTk1YWnpURWtHWDZDd2pzbCs2OFhiUXJuY1NBMlowYU5y?=
 =?utf-8?B?cHBZOUhuZXNaS3R2MDFDeUxiaHIwS2Y2N0krcWhuZEtVVDZ4VnppVDZ3NFBO?=
 =?utf-8?B?NjlWZ2k0a05ITlBmZ29SMUxPTG1FVUM0ajdBRzJuVkJWT2E3Q1RZbmRlVEtq?=
 =?utf-8?B?U053RmQ3bDNuZkxYMzVNVkxGWXQxU0JldTVKbTgyWWl1ZThTRFRJeUlGNmpD?=
 =?utf-8?B?MkJZVDArNEdvb21RaUE4d1N6VWMzelVmUGtEeU41YjBvRkRybDBTakZrU3Vs?=
 =?utf-8?B?TzdBNHlNcDJDOWwvTndBa2ZldHV3WVNVMFFBMjVER0xWT2NXR3pzVzNtdjdr?=
 =?utf-8?B?bzZqVXZDSmN2YlVka01XWncrMEN5a2MzSTlPZXBpNW1tYldkWVlwaGUzTnVw?=
 =?utf-8?B?c0cxMnFTSlduZ0NQUklEZlZBZ2xUMTRsU3A1UExjOCtFQU0rM3BWRWRLMkE5?=
 =?utf-8?B?TmNXT0owYmQvM3Y1cHE3aFl5WnBQbTJxSHRYZ0pET0V4ZW5VOXFSVnZQT0tY?=
 =?utf-8?B?cHlzcWRsVjYxV0ptNWc0TVFLQWVkNjY1ZTV5cTJqWlVOVERGUGxCdSs2MW03?=
 =?utf-8?B?L0hseWRCWUJMWmc3VFlaUk5hNnhrR1NGRURQM0x1c2dIM0pDYzhZcGFYMWtm?=
 =?utf-8?B?eVVPMTdGSTZKVCtNQ1hSTklxQWQ0V1dLSFpvOU5ENXovcC9tdlJJUTJDS1pn?=
 =?utf-8?B?Rmt5akV5NjdSNXd3ZFZHem5NR2JJUExrTUJnR0p4MXdlbmlxRDFGODNtalIw?=
 =?utf-8?B?WUUxdDMzYmRJektncHR5bjkzdjBJcWpJdWN2Y3ZwUFg0MGx4NTZwZkcyWVB4?=
 =?utf-8?B?MkNBb2YyM0t3RVhBUUlYTUg1R1ppZDlJMHFSZjl0WTQ0ZUE5WTRib3VjMnBF?=
 =?utf-8?B?b0N4WlJxUSsyZzYwV1I4eGxLWHA5MTkyNEdabXdRdzdUblk5ZEJRVjJwODZt?=
 =?utf-8?B?c2c9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 32d076ec-272c-4a99-0ea7-08db323e9f9c
X-MS-Exchange-CrossTenant-AuthSource: CY4PR11MB1862.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2023 23:21:15.2321
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: I2buoBQMKlqlTM0IcfFC1ZZeNbQOL/c41olWBKsFqIxz/O2WWEb2Hcz0vXrgmzEUQpGLsHCqhkueWYWGAGxbAhhjx+38eJc24oennimaUCM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6426
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE
        autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi James,

On 3/20/2023 10:26 AM, James Morse wrote:

...

> +/**
> + * resctrl_closid_is_dirty - Determine if all RMID associated with this CLOSID
> + *                           are available.
> + * @closid: The CLOSID that is being queried.
> + *
> + * MPAM's equivalent of RMID are per-CLOSID, meaning a freshly allocated CLOSID
> + * may not be able to allocate clean RMID. To avoid this the allocator will
> + * only return clean CLOSID. This is enough for now as it allows MPAM systems
> + * to use resctrl. This suffers from the problem that there may be no CLOSID
> + * where all the RMID are clean, causing the CLOSID allocation to fail.
> + * This can be improved (once MPAM support is upstream) to return the cleanest
> + * CLOSID where PMG=0 is clean. This would allow the CLOSID allocation to

Why does PMG=0 have to be the clean ID? 

I am wondering about the use cases here. When a new CLOSID needs to be allocated,
would it not be useful to instead have a utility that returns the "cleanest" CLOSID?
Instead of picking an available CLOSID and then always have to check if it is
"dirty or not", why not have a utility that picks the CLOSID with the most
available PMGs?

Reinette