Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Date:   Tue, 31 Oct 2023 08:58:46 +0100
From:   Maciej =?utf-8?Q?Wiecz=C3=B3r-Retman?= 
        <maciej.wieczor-retman@intel.com>
To:     Ilpo =?utf-8?B?SsOkcnZpbmVu?= <ilpo.jarvinen@linux.intel.com>
CC:     <linux-kselftest@vger.kernel.org>,
        Reinette Chatre <reinette.chatre@intel.com>,
        Shuah Khan <shuah@kernel.org>,
        Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>,
        Fenghua Yu <fenghua.yu@intel.com>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 21/24] selftests/resctrl: Get resource id from cache id
Message-ID: <ok6hd2zpswhmxq7vsychb7cqmtqkgadfqq6cz4uxtyourrktxb@tkapqzdmqn42>
References: <20231024092634.7122-1-ilpo.jarvinen@linux.intel.com>
 <20231024092634.7122-22-ilpo.jarvinen@linux.intel.com>
 <cb2ctfignowlom7lb2t5zhdgtm4s2jlzlvtumlnvxecwwtjk34@ysgepmgkv6bb>
 <ab4c6aa5-ea49-363a-ff7b-2215665f185d@linux.intel.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ab4c6aa5-ea49-363a-ff7b-2215665f185d@linux.intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?xVms6JtswUMcrXjPzlngVmARkR+CSEukcrXV+AdEWaX7wMHBa1vm8o6yLY?=
 =?iso-8859-1?Q?OI+vtaVCMqq5HKLUnqVhrITnzU5IL/KWlJuDj5F76+90PzG0OIvsFOn/Sa?=
 =?iso-8859-1?Q?4AyR8j/KiMxYK4Jv5hvGBlWfdq5KStQsP/6XawuVEPlLR5pw8qiQbLgHqi?=
 =?iso-8859-1?Q?vJejQLChqvEr8ZGq51T/dh8iywJUIlEjVKnLfot2zrC91PtIyAJBrVRYwt?=
 =?iso-8859-1?Q?G1wdxeyDHI0nEqi70f1E11xtXKZr4Iy3LYBLMQVxCD1C8o+ZaIBh7sw8sc?=
 =?iso-8859-1?Q?SfYKx+6P46rVpNIYh12npp0nGIvOF1qr4qlmKSENNOJxZg4taMrItU3S6R?=
 =?iso-8859-1?Q?eMQXBHT+66UE12QRA795eV1Ynfhxme4g76sqykrWOHdLUBhnyZ7+dDEaTl?=
 =?iso-8859-1?Q?BqfkJOvt4PnMBiucjWaTDb5k1bmGbiTcc2bPNEtyQ3fblS9rHiG9iJ6J5Q?=
 =?iso-8859-1?Q?KaQu9aRz3zNPiGQvYu5yBGj4d2wpgK1l5hsDYMpcBLghs+oOMf5xYXPg30?=
 =?iso-8859-1?Q?7Xuw/CY+Anc/9kbQw/hBIYvq5uAf1cWFiWZ/96kOJYv3a5I+CCPMJ1Goho?=
 =?iso-8859-1?Q?3XJ6WbmM7IUQI8X3c1TrIClVuH5MepRGGVyDNKirrdOkWTpigp7k2fAH3+?=
 =?iso-8859-1?Q?CJRamq+kPh2zTAF1QBQNJmiXrMZew2ri9EXXsoYNVS6O8fzcKCrBFUgRtQ?=
 =?iso-8859-1?Q?JKLSRWs18jw9D7F/6iWwCT7CI+x3TtcQbbhXRp1wJ4ezy961avlHo9BhKF?=
 =?iso-8859-1?Q?4TzXjtDEVLg9bI4qkNXYLxrniraqEEy1A5VaJ1PuC1pD1LWnnu1cPXIBXu?=
 =?iso-8859-1?Q?nj62W03aIuK4lmDyQygTD/hgDuj7nLtQTC1oWRFGSr2kYN1wOjRF1DG/92?=
 =?iso-8859-1?Q?xeyoIKvUuVO+px17EyqSONkZiR8m5lnNNxOM7lTwtKPsz33nBK1RhlCVBy?=
 =?iso-8859-1?Q?5k90d/1+ZzqQiMYmlR7vKAODeIad1xZ4tkNMEdTO268QN+vIllv70K8B7D?=
 =?iso-8859-1?Q?2+WFBYJZNHRK6gC+HbY1mnlltOmNJMWgEmjMF/vNkQNm5/tP5ipuV/VQ4X?=
 =?iso-8859-1?Q?0SnpX5sDPb+GGPjodWK17B9lm34jWxBMztzlZhjBkUO/Db0OGy1/esroKB?=
 =?iso-8859-1?Q?0MrayOJLrgQVjLyhY49vq+/XxVYc9d9rkEmra6ah88ZTYJSiErw+3WzWNt?=
 =?iso-8859-1?Q?7mtjUop3oc+QmPoH3ex+rjTtrd/geeZw87cDuh6ou4OB6j+/TVNSIdwgl0?=
 =?iso-8859-1?Q?qCcK1ggj4PQta6eQj8T8f5YyuEGk0n/ZOUKiSiuf8Xo6nXYD+RtFKk89Eo?=
 =?iso-8859-1?Q?8qfopDsxRq2d80dzAjE3/hUZ79APbhW4TD9LgSvIt7MKOLtpGLkNheRDkx?=
 =?iso-8859-1?Q?tALvZ4uI+kegRtQjVLHPB3V3FkMfEb47qS5K2NcYjn6bLwHjqIdpYLDqF9?=
 =?iso-8859-1?Q?ddDTgMxWbwpLdQXYf+ryko4RnhydIGVbS5YiMaCXDPdfiaS84gj+xasH3O?=
 =?iso-8859-1?Q?UWEmjXplwaSw2CtlQ459JtwQaql8Jeh+Jw+dB5RExjZxqMFnedggoaxnzq?=
 =?iso-8859-1?Q?0/zjlEBJZiYQRLiln0E0KguJD9/qodJ59j4uKoSDgtzlirpoKPUvefrQXv?=
 =?iso-8859-1?Q?2iqbQsncqoOeUtNXM/1cUi8zbbZflaitcLqrLhjgyKJDus7nZo47s1D12h?=
 =?iso-8859-1?Q?39pW0K0Bnmg9w+DZd5U=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 03e02aaa-0814-4300-f24c-08dbd9e738da
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6239.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2023 07:58:52.8132
 (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: 9oRCdoFg1JxQoDJXbO3knlsknLs1MjDPjnPwWHJKUcykcjZwQ8FTGXBqIqqIk6HZ+mzlBp9F6KzGsHxI/JyCH4sq3hFZylu2tpE/gLVTDRs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR11MB6981
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,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 lipwig.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 (lipwig.vger.email [0.0.0.0]); Tue, 31 Oct 2023 00:59:21 -0700 (PDT)

On 2023-10-27 at 16:30:38 +0300, Ilpo J?rvinen wrote:
>On Fri, 27 Oct 2023, Maciej Wiecz?r-Retman wrote:
>
>> On 2023-10-24 at 12:26:31 +0300, Ilpo J?rvinen wrote:
>> >Resource id is acquired differently depending on CPU. AMD tests use id
>> >from L3 cache, whereas CPUs from other vendors base the id on topology
>> >package id. In order to support L2 CAT test, this has to be
>> >generalized.
>> >
>> >The driver side code seems to get the resource ids from cache ids so
>> >the approach used by the AMD branch seems to match the kernel-side
>> >code. It will also work with L2 resource IDs as long as the cache level
>> >is generalized.
>> >
>> >Using the topology id was always fragile due to mismatch with the
>> >kernel-side way to acquire the resource id. It got incorrect resource
>> >id, e.g., when Cluster-on-Die (CoD) is enabled for CPU (but CoD is not
>> >well suited for resctrl in the first place so it has not been a big
>> >issues if test don't work correctly with it).
>> 
>> "not been a big issues" -> "not been a big issue"?
>> 
>> "if test don't work correctly" -> "if test doesn't work correctly" / "if tests
>> don't work correctly"?
>> 
>> >
>> >Taking all the above into account, generalize the resource id
>> >calculation by taking it from the cache id and do not hard-code the
>> >cache level.
>> 
>> In x86/resctrl files group of CPUs sharing a resctrl resource is called a
>> domain. Because of that I think "resource id" terms should be substituted with
>> "domain id" to match core resctrl code.
>
>Okay, I was just using the terminology which pre-existed in the selftest 
>code.
>
>I've really tried to look how I should call it but things were quite 
>inconsistent. The selftest uses resource id and reads it from cache id.
>Documentation uses "instances of that resource" or "cache id" or "domain 
>x".
>
>
>Documentation/arch/x86/resctrl.rst is very misleading btw and should be 
>IMHO updated:
>
>Memory bandwidth Allocation (default mode)
>------------------------------------------
>
>Memory b/w domain is L3 cache.
>::
>
>        MB:<cache_id0>=bandwidth0;<cache_id1>=bandwidth1;...
>
>It claims "domain" is L3 cache (and the value we're talking about is 
>called "cache_id" here which is what you just called "domain id"). I 
>suppose it should say "b/w resource is L3 cache"?
>

I believe so. After some looking around it looks like the "L3 domain" naming is
also present in rdtgroup.c:mkdir_mondata_all() and "mon_data" description in the
docs:

Docs:
	"mon_data":
		This contains a set of files organized by L3 domain and by
		RDT event. E.g. on a system with two L3 domains there will

rdtgroup.c:
	/*
	 * This creates a directory mon_data which contains the monitored data.
	 *
	 * mon_data has one directory for each domain which are named
	 * in the format mon_<domain_name>_<domain_id>. For ex: A mon_data
	 * with L3 domain looks as below:
	 * ./mon_data:
	 * mon_L3_00
	 * mon_L3_01
	 * mon_L3_02
	 * ...
	 *
	 * Each domain directory has one file per event:
	 * ./mon_L3_00/:
	 * llc_occupancy
	 *
	 */
	static int mkdir_mondata_all(struct kernfs_node *parent_kn,
				     struct rdtgroup *prgrp,
				     struct kernfs_node **dest_kn)

From the reading I've done on resctrl my understanding was that L2/L3 are
resources that can be shared between domains.

-- 
Kind regards
Maciej Wiecz?r-Retman