Message-ID: <052a8700-bae1-a945-c8d0-df658697142f@intel.com>
Date:   Thu, 2 Feb 2023 15:45:15 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.6.1
Subject: Re: [PATCH v2 04/18] x86/resctrl: Move rmid allocation out of
 mkdir_rdt_prepare()
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: <20230113175459.14825-1-james.morse@arm.com>
 <20230113175459.14825-5-james.morse@arm.com>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <20230113175459.14825-5-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?aDZvMks3T01kZTdyRVg1OUczNDRoVXEvSmdmSGQ2QXlLUkNNcXc0dUhIVXgr?=
 =?utf-8?B?bDkwRWRLNFRaemRIRjdtcXdOUHJpbDJETjR6TjFQV1pYVEdmNzFyTDlUL0Fy?=
 =?utf-8?B?R3FXYlFsVkZEV1B0bG9oTk1NR2RIT1pEalBnVE1FK1E5cjJMcXMyNkxSTG9C?=
 =?utf-8?B?ZXlGT1JBMHBpMUFmQnhjd0J1TUtja0tBVUp6aExjODg1NjdiNmozY3FQZVhD?=
 =?utf-8?B?ZTMzV3lQUXNJcndUMmViMnJhdjdpM1RlYTgxQytkUzRsaEJmUEFKTzZnVXA2?=
 =?utf-8?B?eG1sMWdwOFo5U2FoU0VTVUN1b3E1WWxMVkM0VmJVRTdieFIrdm02WnJuWXYy?=
 =?utf-8?B?TkdkQkpvd0prUzRXZWx4NFNuWHpVOGNZaWJEa1BRZXR6VkxEelNaR28zYUdQ?=
 =?utf-8?B?SlY2eW45U05uVDc2N3QwTTJnV3p6enhpRXVEVE9yY1hFTk5Sdi85eC9naXpK?=
 =?utf-8?B?dmtQWm91SnNyOS9QU0N5bWJiYTFXaVJWQmJYdUh0bEQ5OFVNN2c4QWdKalRN?=
 =?utf-8?B?QWYzdm1SSmNST3k4alpuU2psVmQ5cTJpVmVweHl1WE8ySFZScjk2TzZIUWJy?=
 =?utf-8?B?OHM2RGNYRWpocDhkVlBHN0hKQ1diaHd0Z2ZaVTRyNVFEL01SMERrVm54YW5M?=
 =?utf-8?B?eGt0MXExZGdKdTNEYzVJajlmMVBOWDkzZXlWWVIwcjBlY2dTL014OSszNEVF?=
 =?utf-8?B?Y1hsd0Z3VGJOVzRMUm1YczMvZ2VVY2NVOE94THBuNlFUejhKU2tEOTJmdHZ4?=
 =?utf-8?B?cTB2emVxbGdidmxYSTNKc3hGbDZBWktMczB6OWhSWVJNT09FSHdNR0laZVZG?=
 =?utf-8?B?Qjl1cGF3MFY4RVpvQ0NqTmQwMjJ5OGUxdkh1alRGMXZ4UE9ONjZSK3Ivam9X?=
 =?utf-8?B?czhPQmw5T2xJUGpIOGlkVWFxYmZCajNSdDRkMWw4MXRrbzVvdnNrUUFWUVkv?=
 =?utf-8?B?N1piSkZTQUNhQmJ1M1BYTFcwRXltVXFvM0x5WVJ0aUhvSFpMSlRCVUQ5cit5?=
 =?utf-8?B?WUVpMHZqTjdmOWl4N0FuSWw2SnR4RU93cXVVcWZJU3IwT1QwTWtWcVdZdkkz?=
 =?utf-8?B?QXdJcmVkcEZKdzA0UXVGbTJrUkk5ZnBJY1pxS0ZNdElxVTNYbE1ldkhFRS9Y?=
 =?utf-8?B?VUxGdXhGWnRRdUlmZGM5aGRselVBNStrd3hGZGsrWSs5cjkrOFREa2FsUnNQ?=
 =?utf-8?B?R0o5Ti8zNmpBSU1TY3A4bld6anVGME1QUUxGblRMdkhkMldjTnV4dzhQV2Zy?=
 =?utf-8?B?WTFRQThkS3dXVllkRC9wQUprQjBVd3BoZUpMQkQxck5uOXl3ZnR2eFNmSmsx?=
 =?utf-8?B?cldTam1saWp0MlV4OE9DVVBmeENkbE1qM1JJY1RQSW1ONGdmamVrWjBQdDZH?=
 =?utf-8?B?SG5NeWtIdkNINU90M2JTUVYxajEwczQ1M2phN1JlSUFoUmFpek1ZUTJxM1ph?=
 =?utf-8?B?SDN1a1poSkdaZkZ3V3VCYUN3d0JoZFY1dTB4T2FPeXY5TzJCSTNHdzhicWhC?=
 =?utf-8?B?a1hpQm5NNmd5Vzk5OE5WRE12SDhIK29jaHNyNjNNb1FDSjF3WnlCdU9xZUJQ?=
 =?utf-8?B?YVFpenVzMHg5eVlLcklaNnRUdVhLTTdtdXgvc0F1UGxsa2dYcWJod0IzOUZo?=
 =?utf-8?B?KzJUd1hwQWhERURIOTF3R2xxNE9LcytZVG0zSWxEempSWjYzckZGcytpc1Zy?=
 =?utf-8?B?aWY3dnhHSlJkeU1YWEN6amxnVVQ4ZU01L0NVVjB5VVkvOHRzSHlXRDhBQXBV?=
 =?utf-8?B?Nzc1SUFoU2dQODlIK1ZMd2haS2RPU2JhM3FBUXJkelFRbUtvZnBHZ0hIVlEy?=
 =?utf-8?B?RHh6SmhrUHNLVEhLRzJqUGxhSUNnRU1zU29zS0I0aVl0SHpreWtoNE8yU0t0?=
 =?utf-8?B?eHI1cGRaTUpsbmd2ajd5bE93NjlWNTdGUWcvNGh5dEZzZXdVb1hCRDVzT2hG?=
 =?utf-8?B?bjFYRXZMdVhWcVo4NTk5emIxdGtWN1FEMGlKeGZBMVNFMWVpUzlLQjBleVhz?=
 =?utf-8?B?Ri84SFRaSFl2NzBEL3BSem9WVVM1Rm5ldHEwa09oYWpxczdENS9JK0QrQW8z?=
 =?utf-8?B?SnZXRXA0eEdITXJZcERsRi9DV09FUGkyQnZLUEhOYnZ0bHNYNWU0MWxncURp?=
 =?utf-8?B?c1BNc1BDN2VSTEZvMTJpQldVZFBSbWlQekdTcitvMU5zZ1RVY1F5NVNSaldZ?=
 =?utf-8?B?NGc9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: dd806ac2-a3a4-4041-cb54-08db05778a42
X-MS-Exchange-CrossTenant-AuthSource: CY4PR11MB1862.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2023 23:45:18.4281
 (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: /0jSMsIyHix8krUl1GTHyDqlfN6IrUI+nTjMT+uPaNY2MH/Tqs2NHEb05JS1Hoz/jE6JHjbEGiNewA3UCqeXJVZoY2eprhF+80nUuwHbJSc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR11MB6175
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi James,

On 1/13/2023 9:54 AM, James Morse wrote:
> RMID are allocated for each monitor or control group directory, because
> each of these needs its own RMID. For control groups,
> rdtgroup_mkdir_ctrl_mon() later goes on to allocate the CLOSID.
> 
> MPAM's equivalent of RMID are not an independent number, so can't be
> allocated until the closid is known. An RMID allocation for one CLOSID

Could you please be consistent with CLOSID vs closid (also RMID vs rmid)?
When reading through the series and seeing the switch it is not clear if
text refers to same concept.

> may fail, whereas another may succeed depending on how many monitor
> groups a control group has.
> 
> The RMID allocation needs to move to be after the CLOSID has been
> allocated.
> 
> Move the RMID allocation out of mkdir_rdt_prepare() to occur in its caller,
> after the mkdir_rdt_prepare() call. This allows the RMID allocator to
> know the CLOSID.
> 
> Tested-by: Shaopeng Tan <tan.shaopeng@fujitsu.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
>  arch/x86/kernel/cpu/resctrl/rdtgroup.c | 29 +++++++++++++++++++-------
>  1 file changed, 22 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 841294ad6263..c67083a8a5f5 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -2892,6 +2892,12 @@ static int mkdir_rdt_prepare_rmid_alloc(struct rdtgroup *rdtgrp)
>  	return 0;
>  }
>  
> +static void mkdir_rdt_prepare_rmid_free(struct rdtgroup *rgrp)
> +{
> +	if (rdt_mon_capable)
> +		free_rmid(rgrp->closid, rgrp->mon.rmid);
> +}
> +
>  static int mkdir_rdt_prepare(struct kernfs_node *parent_kn,
>  			     const char *name, umode_t mode,
>  			     enum rdt_group_type rtype, struct rdtgroup **r)
> @@ -2957,10 +2963,6 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn,
>  		goto out_destroy;
>  	}
>  
> -	ret = mkdir_rdt_prepare_rmid_alloc(rdtgrp);
> -	if (ret)
> -		goto out_destroy;
> -
>  	kernfs_activate(kn);
>  

This moves the creation of the monitoring related files/directories to later, but leaves
the kernfs_activate() that activates the node and make it visible to user space. Should
this activation be moved?

Reinette