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 3C75FC6787B for ; Fri, 25 Aug 2023 17:51:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230104AbjHYRul (ORCPT ); Fri, 25 Aug 2023 13:50:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234197AbjHYRuc (ORCPT ); Fri, 25 Aug 2023 13:50:32 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BDBD213B; Fri, 25 Aug 2023 10:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692985830; x=1724521830; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=BMuydG6qd8dGt72QIXVZ69QQMN032z1ooN3auzKbqYg=; b=nbBRdoNumrcjtWVijPq1Id32353OIwo6eEt0PHge1Tn+Pcm67bc/Ou85 4Vgqqo5lHNPuJ14cDHluyigGthFRmAj5EJXQiK+NVyMau69zLxoKHFqcU lxgUwIiTPlXUVkj9tEIUC1+0AwhD1pCfzxL897lXWseZW4NLmI5ZxFLSO KBXCOvZPh5h1CoZtHK2acBsm31BY1e83qH6JjXlsfLR7Yh5Q3An9pSXeB Z3JOVn4cWZhDl6zlGap/sIC0GG0O65pSEFbQJfcREUuht2B2M+2jHfFyc UKY+BTqlBgwtehW7b2O1riz5aqV7izV4l8isjILGe7E6PccxGeMlVw36I w==; X-IronPort-AV: E=McAfee;i="6600,9927,10813"; a="355097971" X-IronPort-AV: E=Sophos;i="6.02,201,1688454000"; d="scan'208";a="355097971" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2023 10:50:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10813"; a="687401384" X-IronPort-AV: E=Sophos;i="6.02,201,1688454000"; d="scan'208";a="687401384" Received: from agluck-desk3.sc.intel.com (HELO agluck-desk3) ([172.25.222.74]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2023 10:50:28 -0700 Date: Fri, 25 Aug 2023 10:50:27 -0700 From: Tony Luck To: Reinette Chatre Cc: Fenghua Yu , Peter Newman , Jonathan Corbet , Shuah Khan , x86@kernel.org, Shaopeng Tan , James Morse , Jamie Iles , Babu Moger , Randy Dunlap , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, patches@lists.linux.dev Subject: Re: [PATCH v4 6/7] x86/resctrl: Update documentation with Sub-NUMA cluster changes Message-ID: References: <20230713163207.219710-1-tony.luck@intel.com> <20230722190740.326190-1-tony.luck@intel.com> <20230722190740.326190-7-tony.luck@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Fri, Aug 11, 2023 at 10:33:18AM -0700, Reinette Chatre wrote: > Hi Tony, > > On 7/22/2023 12:07 PM, Tony Luck wrote: > > With Sub-NUMA Cluster mode enabled the scope of monitoring resources is > > per-NODE instead of per-L3 cache. Suffixes of directories with "L3" in > > their name refer to Sub-NUMA nodes instead of L3 cache ids. > > > > Signed-off-by: Tony Luck > > Reviewed-by: Peter Newman > > --- > > Documentation/arch/x86/resctrl.rst | 10 +++++++--- > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/arch/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst > > index cb05d90111b4..4d9ddb91751d 100644 > > --- a/Documentation/arch/x86/resctrl.rst > > +++ b/Documentation/arch/x86/resctrl.rst > > @@ -345,9 +345,13 @@ When control is enabled all CTRL_MON groups will also contain: > > When monitoring is enabled all MON groups will also contain: > > > > "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 > > - be subdirectories "mon_L3_00" and "mon_L3_01". Each of these > > + This contains a set of files organized by L3 domain or by NUMA > > + node (depending on whether Sub-NUMA Cluster (SNC) mode is disabled > > + or enabled respectively) and by RDT event. E.g. on a system with > > + SNC mode disabled with two L3 domains there will be subdirectories > > + "mon_L3_00" and "mon_L3_01". The numerical suffix refers to the > > + L3 cache id. With SNC enabled the directory names are the same, > > + but the numerical suffix refers to the node id. Each of these > > directories have one file per event (e.g. "llc_occupancy", > > "mbm_total_bytes", and "mbm_local_bytes"). In a MON group these > > files provide a read out of the current value of the event for > > I think it would be helpful to add a modified version of the snippet > (from previous patch changelog) regarding well-behaved NUMA apps. > With the above it may be confusing that a single cache allocation has > multiple cache occupancy counters. > > This also changes the meaning of the numbers in the directory names. > The documentation already provides guidance on how to find the cache > ID of a logical CPU (see section "Cache IDs"). I think it will be > helpful to add a snippet that makes it clear to users how to map > a CPU to its node ID. Added extra details as suggested. > > Reinette -Tony