Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Message-ID: <1dc0fb2f-7b68-d1b3-e6fe-bf341afb545d@amd.com>
Date:   Thu, 5 Oct 2023 15:26:38 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Reply-To: babu.moger@amd.com
Subject: Re: [PATCH v6 10/24] x86/resctrl: Allocate the cleanest CLOSID by
 searching closid_num_dirty_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>,
        Reinette Chatre <reinette.chatre@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,
        dfustini@baylibre.com, amitsinght@marvell.com
References: <20230914172138.11977-1-james.morse@arm.com>
 <20230914172138.11977-11-james.morse@arm.com>
From:   "Moger, Babu" <bmoger@amd.com>
In-Reply-To: <20230914172138.11977-11-james.morse@arm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?anFzbTdxaDIrNTQ3RHlQYlRncm8rK3lFeE9aZm81ZGl0OEUvLzJpdWJqRlgz?=
 =?utf-8?B?VTF5NmpzOGJzOVU0eFBKLzRPdWhIZ3hoT0ovOGx1ZEk2QlpRZ1BWR2V2VW4y?=
 =?utf-8?B?V2RUaXpFSDIrQjFuTzBWZEhPUWI1UzZsNzVLNlM0TVdtUHcxZ2NQK3Q5N0tv?=
 =?utf-8?B?TnJRZzJDZ3pHczRjQ1ZXWWFEelNmUFJNOWt3VmhNUzB0bUlBei9oU0hubVp6?=
 =?utf-8?B?cEFtOTQ2UUxDNUFXSDlxWDAySXB6TWNGQUZJSlM0cmdqZENqdlFnZFR6RE4r?=
 =?utf-8?B?SGhNbSs4amVvV1c2ZktadlpjaThFWXZzQmZERThsSjY0MDJiMi9aNU1XVkhj?=
 =?utf-8?B?SndFUDBsaXVQZFFITkVqZHVxTDgveU1LcTJEbEtQbjdqNUhSdW9mMFlaZzQy?=
 =?utf-8?B?NFRCbjZBZVYzUUJ3S1BCeWc1TnNQeVJOVERkTjh6S3dWVTduMGdsNkxsMlQ5?=
 =?utf-8?B?N3VERVk1R3orakYvQ1FSTlJmL0lyM2ozbzVxa1MyaU9IMkhVdEJtUG03QnYw?=
 =?utf-8?B?MllXRlFQRGtGM2E3L0tucUhMdnpZMmFRTWg4WFJWZTdIK2taTUZPTXpiN29x?=
 =?utf-8?B?dGhxMEdFbGdOcUwzT1ArRFVXem1YQUsrTEJHcTM2b2s4YXdER0RvWGZDbDhr?=
 =?utf-8?B?TmlkT1E1VnFvenBhdW9nMGJHejlsS1R1WUJEMkFxNkJ5VnBpeU0zN2xyZGFV?=
 =?utf-8?B?S1JLbisyS01ZUWkxV1c5NDVWdTlHVFVNbnRDdzFSTXY2ZTIxcWFsWG1zWXNF?=
 =?utf-8?B?VDZNY2hKYzBEdU9JczJpNThBMFpoWjI0N1pZakRralk0cis1NWo4Yms0OWxl?=
 =?utf-8?B?MzFNZE4zbFR2WHdpejJoamtDVThUU3d0NEd2VjYvL1hocjZzNjVhUWNoc1VH?=
 =?utf-8?B?VDlOZDgvUXp5YlMweDdxSnBWT1JhRys0RnRCYnloYVlFam5WU1JRcHdqdVFG?=
 =?utf-8?B?YWVwcEYwZGJoQzRwTUlXMkI4ZGtmTWY0N2ZiM2ViUmovQmxkUlNOc0duRW5i?=
 =?utf-8?B?TjVzZmhmNGM2U2NNWXlkbnJ3ZXhjR2t2TXcwTU1idnl3WEF0U1dveWh1Y1VR?=
 =?utf-8?B?Y2E4YVhSeDJMMTF6QzBqMEhGbEY3N1dLQVZKTE0yN1dieG15RGJwM0cyUjZz?=
 =?utf-8?B?Uk9UaEt0cy8xUlRyRGxJbDkzYkgzOENnZzJDSzA1d2hOUjQvemVxV003Qjlj?=
 =?utf-8?B?Z0FVWFlNUGlZYUYvazYwSTZpa0gyQjFKaEVOMnhmYjFSV1kvR0k2Zm9HbE9T?=
 =?utf-8?B?aVZhNzNmYlN3aSttdFNKTXZWQkNQSkx1cUlheFRnTkNET1ZHVXhDTUZpcllX?=
 =?utf-8?B?eVdzODYwRWlQZGJCb3U0RVBjQTJSUForY2pEQmhNOXV3QkFzbTkweVUySHVo?=
 =?utf-8?B?bGNUSi9LNzltQjUyRDZsUWs0anQzNGtoczFaakJocHlmWEk3SWpDbktSL1Q5?=
 =?utf-8?B?OTJWTDE5d1BUd0FZKzRUQU0zd0FBVTVBNjVpQU9DRkFwQSthaXg3MS9XTjlU?=
 =?utf-8?B?Y2drN3ROQit0WlhXNHFVbTJ3bUd0Q0NMaGI4NVZsbjl2dnNubTdLSnFqU3E4?=
 =?utf-8?B?dzdscmxNcElKWlUxWVA2SXQ5T2k4NFlQTWtEMnUzNDFiY1ZlaGIxSGVhS1M1?=
 =?utf-8?B?ajJ3blptSnd2U2p4c3NSUVI3WFpTZ2JLYXNWbjNZK1YxQmNlRlkzbkF2YVBR?=
 =?utf-8?B?VCtBcU9XSkgzT2VMUU1TeUZoUmduWGxZYzltTUw4U3hvQVNVeGg1ckdtb3JH?=
 =?utf-8?B?TldXVWxoMTdraTU1L3RGVlYvdHd0Nm54eVNtUjdBa1FiZC9EenNoUm5UTFJ5?=
 =?utf-8?B?cnRxaXBRbXNLSXlZeGZNSW1LY3BNNktIK05YclZFUUhwcjYwSHFWZ2xBYzFD?=
 =?utf-8?B?VnVMc0lKNm05ZXNIdmFOSkJBSUFqRUVLYm5tblJiVFF1azRPZDZHQ1lhZXor?=
 =?utf-8?B?ajJyWW92VE0rUzN4WmhkN1o0N1NQR2JNT2ZNTmRmVXFLb0d2THoyL1pzcWFQ?=
 =?utf-8?B?aE5IUS83OTBSNUExYzhPaGJyT0dVWnBjcmdlRXJ0bm82MXcxelNicENQZ2FJ?=
 =?utf-8?B?WDk2NUZOMlJhY0tDcXR4c2lLYktnMkVmRU1aMWd2cGJHUXJXMjl0Ym5uMHJ2?=
 =?utf-8?Q?ynySW7K6XbtR4M6cRx5M/WKq6?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 841c1597-e4bb-4641-a73f-08dbc5e163bb
X-MS-Exchange-CrossTenant-AuthSource: MW3PR12MB4553.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2023 20:26:43.5834
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: rOPdF9H4MPAsKt+MmrNn3E/+iQsLdd6FSp3KTWHHBgvF9xPClUDUAQgYzPV+RwBm
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6362
X-Spam-Status: No, score=-4.1 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 05 Oct 2023 13:27:04 -0700 (PDT)

Hi James,

One more comment.

On 9/14/2023 12:21 PM, James Morse wrote:
> MPAM's PMG bits extend its PARTID space, meaning the same PMG value can be
> used for different control groups.
>
> This means once a CLOSID is allocated, all its monitoring ids may still be
> dirty, and held in limbo.
>
> Instead of allocating the first free CLOSID, on architectures where
> CONFIG_RESCTRL_RMID_DEPENDS_ON_COSID is enabled, search
> closid_num_dirty_rmid[] to find the cleanest CLOSID.
>
> The CLOSID found is returned to closid_alloc() for the free list
> to be updated.
>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@fujitsu.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@fujitsu.com>
> Tested-By: Peter Newman <peternewman@google.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> Changes since v4:
>   * Dropped stale section from comment
> ---
>   arch/x86/kernel/cpu/resctrl/internal.h |  2 ++
>   arch/x86/kernel/cpu/resctrl/monitor.c  | 42 ++++++++++++++++++++++++++
>   arch/x86/kernel/cpu/resctrl/rdtgroup.c | 19 +++++++++---
>   3 files changed, 58 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
> index ad6e874d9ed2..f06d3d3e0808 100644
> --- a/arch/x86/kernel/cpu/resctrl/internal.h
> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
> @@ -558,5 +558,7 @@ void rdt_domain_reconfigure_cdp(struct rdt_resource *r);
>   void __init thread_throttle_mode_init(void);
>   void __init mbm_config_rftype_init(const char *config);
>   void rdt_staged_configs_clear(void);
> +bool closid_allocated(unsigned int closid);
> +int resctrl_find_cleanest_closid(void);
>   
>   #endif /* _ASM_X86_RESCTRL_INTERNAL_H */
> diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
> index 0c783301d106..0bbed8c62d42 100644
> --- a/arch/x86/kernel/cpu/resctrl/monitor.c
> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c
> @@ -388,6 +388,48 @@ static struct rmid_entry *resctrl_find_free_rmid(u32 closid)
>   	return ERR_PTR(-ENOSPC);
>   }
>   
> +/**
> + * resctrl_find_cleanest_closid() - Find a CLOSID where all the associated
> + *                                  RMID are clean, or the CLOSID that has
> + *                                  the most clean RMID.
> + *
> + * 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
> + * choose the CLOSID with the most clean RMID.
> + *
> + * When the CLOSID and RMID are independent numbers, the first free CLOSID will
> + * be returned.
> + */
> +int resctrl_find_cleanest_closid(void)
> +{
> +	u32 cleanest_closid = ~0, iter_num_dirty;
> +	int i = 0;
> +
> +	lockdep_assert_held(&rdtgroup_mutex);
> +
> +	if (!IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID))
> +		return -EIO;
> +
> +	for (i = 0; i < closids_supported(); i++) {
> +		if (closid_allocated(i))
> +			continue;
> +
> +		iter_num_dirty = closid_num_dirty_rmid[i];
> +		if (iter_num_dirty == 0)
> +			return i;
> +
> +		if (cleanest_closid == ~0)
> +			cleanest_closid = i;
> +
> +		if (iter_num_dirty < closid_num_dirty_rmid[cleanest_closid])
> +			cleanest_closid = i;
> +	}
> +
> +	if (cleanest_closid == ~0)
> +		return -ENOSPC;
> +	return cleanest_closid;
> +}
> +
>   /*
>    * 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
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index fa449ee0d1a7..1f8f1c417a4b 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -132,11 +132,20 @@ static void closid_init(void)
>   
>   static int closid_alloc(void)
>   {
> -	u32 closid = ffs(closid_free_map);
> +	u32 closid;
> +	int err;

Naming "err" seems odd here.  How about cleanest_closid ?

Thanks

Babu

>   
> -	if (closid == 0)
> -		return -ENOSPC;
> -	closid--;
> +	if (IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID)) {
> +		err = resctrl_find_cleanest_closid();
> +		if (err < 0)
> +			return err;
> +		closid = err;
> +	} else {
> +		closid = ffs(closid_free_map);
> +		if (closid == 0)
> +			return -ENOSPC;
> +		closid--;
> +	}
>   	clear_bit(closid, &closid_free_map);
>   
>   	return closid;
> @@ -154,7 +163,7 @@ void closid_free(int closid)
>    * Return: true if @closid is currently associated with a resource group,
>    * false if @closid is free
>    */
> -static bool closid_allocated(unsigned int closid)
> +bool closid_allocated(unsigned int closid)
>   {
>   	return !test_bit(closid, &closid_free_map);
>   }