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 44F0BC7EE2D for ; Fri, 3 Mar 2023 18:35:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231391AbjCCSfC (ORCPT ); Fri, 3 Mar 2023 13:35:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231893AbjCCSe5 (ORCPT ); Fri, 3 Mar 2023 13:34:57 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 66B3A60A84 for ; Fri, 3 Mar 2023 10:34:51 -0800 (PST) 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 66E12143D; Fri, 3 Mar 2023 10:35:34 -0800 (PST) Received: from [10.1.196.177] (eglon.cambridge.arm.com [10.1.196.177]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 09DE93F93E; Fri, 3 Mar 2023 10:34:45 -0800 (PST) Message-ID: <753cd447-24a8-0dd8-6f35-9ad75ba619c5@arm.com> Date: Fri, 3 Mar 2023 18:34:39 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH v2 05/18] x86/resctrl: Allow RMID allocation to be scoped by CLOSID Content-Language: en-GB To: Reinette Chatre , x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS , 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 , Xin Hao , peternewman@google.com References: <20230113175459.14825-1-james.morse@arm.com> <20230113175459.14825-6-james.morse@arm.com> <2ad21ffe-6019-eb34-a0b3-2c9d26799269@intel.com> From: James Morse In-Reply-To: <2ad21ffe-6019-eb34-a0b3-2c9d26799269@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Reinette, On 02/02/2023 23:45, Reinette Chatre wrote: > On 1/13/2023 9:54 AM, James Morse wrote: >> MPAMs RMID values are not unique unless the CLOSID is considered as well. >> >> alloc_rmid() expects the RMID to be an independent number. >> >> Pass the CLOSID in to alloc_rmid(). Use this to compare indexes when >> allocating. If the CLOSID is not relevant to the index, this ends up >> comparing the free RMID with itself, and the first free entry will be >> used. With MPAM the CLOSID is included in the index, so this becomes a >> walk of the free RMID entries, until one that matches the supplied >> CLOSID is found. >> >> Tested-by: Shaopeng Tan >> Signed-off-by: James Morse > > ... > >> /* >> - * As of now the RMIDs allocation is global. >> + * As of now the RMIDs allocation is the same in each domain. > Could you please elaborate what is meant/intended with this change > (global vs per domain)? From the changelog a comment that RMID > allocation is the same in each resource group for MPAM may be > expected but per domain is not clear to me. This is badly worded. It's referring to the limbo list management, while RMID=7 isn't unique on MPAM, the struct rmid_entry used in two domains will be the same because the CLOSID doesn't change. This means its still sufficient to move around the struct rmid_entry to manage the limbo list. I think this had me confused because 'as of now' implies the RMID won't always be globally allocated, and MPAM has non-unique RMID/PMG values which are a different kind of global. I'll change this to read: /* * For MPAM the RMID value is not unique, and has to be considered with * the CLOSID. The (CLOSID, RMID) pair is allocated on all domains, which * allows all domains to be managed by a single limbo list. * Each domain also has a rmid_busy_llc to reduce the work of the limbo handler. */ (seeing as the function doesn't touch rmid_budy_llc, or refer to it by name) Thanks, James