From mboxrd@z Thu Jan 1 00:00:00 1970 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 EC4B1C7EE2D for ; Fri, 3 Mar 2023 18:33:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231604AbjCCSdW (ORCPT ); Fri, 3 Mar 2023 13:33:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231708AbjCCSdV (ORCPT ); Fri, 3 Mar 2023 13:33:21 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6024A83FE; Fri, 3 Mar 2023 10:33:11 -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 43E1F143D; Fri, 3 Mar 2023 10:33:54 -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 52FBC3F93E; Fri, 3 Mar 2023 10:33:08 -0800 (PST) Message-ID: Date: Fri, 3 Mar 2023 18:32:59 +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 5/7] x86/resctrl: Add a new "snc_ways" file to the monitoring info directory. Content-Language: en-GB To: "Luck, Tony" , "Yu, Fenghua" , "Chatre, Reinette" , Peter Newman , Jonathan Corbet , "x86@kernel.org" Cc: Shaopeng Tan , Jamie Iles , Babu Moger , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "patches@lists.linux.dev" References: <20230126184157.27626-1-tony.luck@intel.com> <20230126184157.27626-6-tony.luck@intel.com> From: James Morse In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Hi Tony, On 28/02/2023 17:44, Luck, Tony wrote: >>> Make it easy for the user to tell if Sub-NUMA Cluster is enabled by >>> providing an info/ file. >> >> I think what this is conveying to user-space is 'domain_id_is_numa_node'. > > That seems more architecturally neutral. I like it. > >> Does user-space need to know the number of ways? > > I don't know. Maybe some might. Perhaps there is some better name that > is architecturally neutral, but still has a numerical rather than boolean value? If we don't know what user-space needs this for, I'd prefer we don't expose it. It'll be a problem in the future if there is no single number we can put there. I don't see what the difference between 2 and 4 would be used for when setting up resctrl, unless you are choosing which numa-nodes to spread tasks over ... but the numa distance would be a much better number to base that decision on. User-space is able to perform the same calculation to find the snc_ways using the cache/index stuff and node entries in sysfs. >> Will this always be a single number, or will it ever be possible to have an SNC=2 and >> SNC=1 package in the same system? > > I sincerely hope that it is the same value across the system. Currently the > BIOS setup option to enable SNC doesn't have per-socket choices, it is > just an all-or-nothing choice. "2" isn't the only choice for number of SNC > nodes on a socket. "4" is (or will be) a choice. Yeah, in the arm world, partners get to make the decision on what is sane. Big-little means someone could do something that looks like SNC in on cluster, but not another. If we don't know what user-space needs it for, I'd prefer we don't expose it, just to avoid giving out rope to shoot ourselves in the foot with. Thanks, James