Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp8217937rwl; Tue, 10 Jan 2023 10:25:23 -0800 (PST) X-Google-Smtp-Source: AMrXdXvIDfnrqboxFTogpS5ab/iNx036dxi07yVLmz35WiAOFAjSGCMit8n5ijk/JAbJDCxEGx5U X-Received: by 2002:a05:6a20:c196:b0:b2:36a6:d7b4 with SMTP id bg22-20020a056a20c19600b000b236a6d7b4mr87695840pzb.27.1673375122814; Tue, 10 Jan 2023 10:25:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673375122; cv=none; d=google.com; s=arc-20160816; b=yOR/fcihP75ThX9fxeCir1TQGQo8npM74kBWpBEKc/vVjVwfd3al/rjt2ugnKhe8mb O7H5JoaSf0ErDs4Fdgn4PzeXqrdgVwmp6TGDPMO0MCV632osPsQDv4zMdmoLx1XKN5wD j/C3+JQKTWGvUjbaD+sn82+t2w71Bt4BuDeyaBUcp6YcK/rjVKMcPftRhoPbFY9qZl7w 0GF7dz251HcvQJ4W2qciK5rxlnN0yAy+S3NaoybXleIh5Xco7ohJGTh5BfCf5Ybuk640 jPl3DjcWOOsf8bIgUgg1ko6LSA4xkpVmFlvZxPeeuKZEtMGXoEQMEODbbTR/T6YLuOdF yE0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=SPNopeNA5EY+70mk1reP7S+vxVgKVwJYFtYmb5sltQg=; b=01FvgpqtPCLnBA6UQ6jmEA8p7mUxnvt6anH/Ytlc9SbB7Od1O9fZ0LlsPSxvZtSutY wLY76+JulNrRG+XcP9lPr+BW8O+ZmWxTafArsIFfd4juKNNfHhb5P8jWTfC2johbgPLX w1h2qNTGO5NxJeXFpQdXd3Fphj/PVvHj+Pie06qpOOVRyffoDSA98dJ9txkHHvdUNWy5 a/MJ0Lcpj/J4Fi0Ugw8Z3GOT7pw4KAqjE3U5c6ByGxCOr8Vh43BQOeEyEaO9fetga4z8 VazgSxz6haW9z7qfpX/p1zaXqVSmBSc0h0+oQ6EyBEMjwS2GoM+NaMrDLh0R+9Dk+GZy gDcw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g22-20020a635656000000b0048a5e036c44si6681526pgm.383.2023.01.10.10.25.15; Tue, 10 Jan 2023 10:25:22 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238636AbjAJSCu (ORCPT + 53 others); Tue, 10 Jan 2023 13:02:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238650AbjAJR6I (ORCPT ); Tue, 10 Jan 2023 12:58:08 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 000F22019 for ; Tue, 10 Jan 2023 09:57:33 -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 455722F4; Tue, 10 Jan 2023 09:58:15 -0800 (PST) Received: from [10.1.196.46] (eglon.cambridge.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 49B603F67D; Tue, 10 Jan 2023 09:57:30 -0800 (PST) Message-ID: <54d14a9f-5983-0a33-9340-c0ff48cc9757@arm.com> Date: Tue, 10 Jan 2023 17:57:19 +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 01/18] x86/resctrl: Track the closid with the rmid Content-Language: en-GB To: "Yu, Fenghua" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" Cc: "Chatre, Reinette" , 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" , Jamie Iles , Xin Hao , "xingxin.hx@openanolis.org" , "baolin.wang@linux.alibaba.com" , "peternewman@google.com" References: <20221021131204.5581-1-james.morse@arm.com> <20221021131204.5581-2-james.morse@arm.com> From: James Morse In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=ham 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: X-Mailing-List: linux-kernel@vger.kernel.org Hi Fenghua, On 06/01/2023 02:57, Yu, Fenghua wrote: >> James Morse writes: >> >> x86's RMID are independent of the CLOSID. An RMID can be allocated, used and >> freed without considering the CLOSID. >> >> MPAM's equivalent feature is PMG, which is not an independent number, it >> extends the CLOSID/PARTID space. For MPAM, only PMG-bits worth of 'RMID' >> can be allocated for a single CLOSID. >> i.e. if there is 1 bit of PMG space, then each CLOSID can have two monitor >> groups. >> >> To allow rescrl to disambiguate RMID values for different CLOSID, everything in > > s/rescrl/resctrl/ > >> resctrl that keeps an RMID value needs to know the CLOSID too. This will always >> be ignored on x86. >> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h >> b/arch/x86/kernel/cpu/resctrl/internal.h >> index 5f7128686cfd..4b243ba88882 100644 >> --- a/arch/x86/kernel/cpu/resctrl/internal.h >> +++ b/arch/x86/kernel/cpu/resctrl/internal.h >> @@ -519,7 +519,7 @@ struct rdt_domain *get_domain_from_cpu(int cpu, >> struct rdt_resource *r); int closids_supported(void); void closid_free(int closid); >> int alloc_rmid(void); -void free_rmid(u32 rmid); >> +void free_rmid(u32 closid, u32 rmid); >> int rdt_get_mon_l3_config(struct rdt_resource *r); void mon_event_count(void >> *info); int rdtgroup_mondata_show(struct seq_file *m, void *arg); diff --git >> a/arch/x86/kernel/cpu/resctrl/monitor.c >> b/arch/x86/kernel/cpu/resctrl/monitor.c >> index efe0c30d3a12..f1f66c9942a5 100644 >> --- a/arch/x86/kernel/cpu/resctrl/monitor.c >> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c >> @@ -25,6 +25,7 @@ >> #include "internal.h" >> >> struct rmid_entry { >> + u32 closid; > > Could you please add a comment for this closid field? It's expected to be form x86 RMID entry. > So it's deserved a comment to explain a bit more on this field. Sure ... what does it need to convey? I'm not sure what you mean by "expected to be form x86 RMID entry". My medium verbosity version looks like this: | /* | * Some architectures's resctrl_arch_rmid_read() needs the CLOSID value | * in order to access the correct monitor. This field provides the | * value to list walkers like __check_limbo(). On x86 this is ignored. | */ Does this cover it? Thanks, James >> u32 rmid; >> int busy; >> struct list_head list;