public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>,
	"Yu, Fenghua" <fenghua.yu@intel.com>,
	"Wieczor-Retman, Maciej" <maciej.wieczor-retman@intel.com>,
	Peter Newman <peternewman@google.com>,
	James Morse <james.morse@arm.com>,
	Babu Moger <babu.moger@amd.com>,
	Drew Fustini <dfustini@baylibre.com>,
	Dave Martin <Dave.Martin@arm.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"patches@lists.linux.dev" <patches@lists.linux.dev>
Subject: Re: [PATCH v18 06/17] x86/resctrl: Introduce snc_nodes_per_l3_cache
Date: Thu, 23 May 2024 13:56:17 -0700	[thread overview]
Message-ID: <013c9532-cacf-4604-b1d9-e90fdc80e7dd@intel.com> (raw)
In-Reply-To: <SJ1PR11MB6083117715CD53FA4360C56CFCF42@SJ1PR11MB6083.namprd11.prod.outlook.com>

Hi Tony,

On 5/23/24 12:04 PM, Luck, Tony wrote:
>>>      return (is_mbm_local_enabled() &&
>>> -           r->alloc_capable && is_mba_linear());
>>> +           r->alloc_capable && is_mba_linear() &&
>>> +           snc_nodes_per_l3_cache == 1);
>>>   }
>>>
>>>   /*
>>
>> Since the software controller is a filesystem feature the above
>> now requires that snc_nodes_per_l3_cache becomes part of the resctrl
>> filesystem code and every architecture will need to set snc_nodes_per_l3_cache.
>> Every architecture will thus need to interpret what "SNC" means for them
>> using the term introduced here. That may be ok ... but the term "SNC"
>> will then surely not identify an Intel feature and Intel needs to be ok
>> that any architecture calls their "similar to SNC but not quite identical"
>> "SNC".
>>
>> I assume now that as part of the fs/arch split there needs to be
>> a new helper that allows different architectures to set this
>> filesystem variable?
> 
> I can change this check to better reflect the underlying reason to
> disable the software controller. Which is that the MBM monitor scope
> does not match the MBA control scope. This seems like an architecture
> neutral expression.
> 
> So code would look like this:
> 
> 	struct rdt_resource *rmbm = &rdt_resources_all[RDT_RESOURCE_L3].r_rescrl;
> 	struct rdt_resource *rmba = &rdt_resources_all[RDT_RESOURCE_MBA].r_rescrl;
> 
> 	...
> 
> 	 return (is_mbm_local_enabled() &&
>                  r->alloc_capable && is_mba_linear() &&
>                  rmbm->mon_scope == rmba->ctrl_scope);
> 
> I'm also contemplating dropping snc_nodes_per_l3_cache from being a
> global variable and making it a field in "struct rdt_resource" (only needed
> for the RDT_RESOURCE_L3 resource). N.B. Babu had suggested it
> shouldn't be global many patch versions ago.
> 
> Perhaps name it .domains_per_l3_cache or .subdomains_per_l3_cache?
> 
> Bad idea? Good idea (but you have a better name for the field)?

With the check in supports_mba_mbps() changed I do not see
snc_nodes_per_l3_cache needed by anything but arch specific code.
I thus do not see any reason for the resctrl filesystem (or, for
example, Arm) to know that this value even exists.

While struct rdt_hw_resource is a place to put architecture
specific information it does not seem appropriate to force every
resource to carry what is essentially a system wide (not specific to
resctrl) L3 specific property. To me this really seems like an
architecture specific global setting but I'd also like to hear the
motivations why it should not be.

Reinette




  reply	other threads:[~2024-05-23 20:56 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-15 22:23 [PATCH v18 00/17] Add support for Sub-NUMA cluster (SNC) systems Tony Luck
2024-05-15 22:23 ` [PATCH v18 01/17] x86/resctrl: Prepare for new domain scope Tony Luck
2024-05-15 22:23 ` [PATCH v18 02/17] x86/resctrl: Prepare to split rdt_domain structure Tony Luck
2024-05-15 22:23 ` [PATCH v18 03/17] x86/resctrl: Prepare for different scope for control/monitor operations Tony Luck
2024-05-15 22:23 ` [PATCH v18 04/17] x86/resctrl: Split the rdt_domain and rdt_hw_domain structures Tony Luck
2024-05-15 22:23 ` [PATCH v18 05/17] x86/resctrl: Add node-scope to the options for feature scope Tony Luck
2024-05-15 22:23 ` [PATCH v18 06/17] x86/resctrl: Introduce snc_nodes_per_l3_cache Tony Luck
2024-05-22 21:08   ` Reinette Chatre
2024-05-23 19:04     ` Luck, Tony
2024-05-23 20:56       ` Reinette Chatre [this message]
2024-05-23 21:25         ` Luck, Tony
2024-05-23 22:31           ` Reinette Chatre
2024-05-23 23:18             ` Luck, Tony
2024-05-23 23:48               ` Reinette Chatre
2024-05-15 22:23 ` [PATCH v18 07/17] x86/resctrl: Prepare for new Sub-NUMA (SNC) cluster monitor files Tony Luck
2024-05-22 21:12   ` Reinette Chatre
2024-05-15 22:23 ` [PATCH v18 08/17] x86/resctrl: Add and initialize display_id field to struct rdt_mon_domain Tony Luck
2024-05-22 21:13   ` Reinette Chatre
2024-05-15 22:23 ` [PATCH v18 09/17] x86/resctrl: Add new fields to struct rmid_read for summation of domains Tony Luck
2024-05-22 21:14   ` Reinette Chatre
2024-05-15 22:23 ` [PATCH v18 10/17] x86/resctrl: Refactor mkdir_mondata_subdir() with a helper function Tony Luck
2024-05-22 21:15   ` Reinette Chatre
2024-05-15 22:23 ` [PATCH v18 11/17] x86/resctrl: Allocate a new bit in union mon_data_bits Tony Luck
2024-05-22 21:16   ` Reinette Chatre
2024-05-15 22:23 ` [PATCH v18 12/17] x86/resctrl: Create Sub-NUMA (SNC) monitor files Tony Luck
2024-05-22 21:19   ` Reinette Chatre
2024-05-15 22:23 ` [PATCH v18 13/17] x86/resctrl: Handle removing directories in Sub-NUMA (SNC) mode Tony Luck
2024-05-22 21:20   ` Reinette Chatre
2024-05-15 22:23 ` [PATCH v18 14/17] x86/resctrl: Sum monitor data acrss Sub-NUMA (SNC) nodes when needed Tony Luck
2024-05-22 21:24   ` Reinette Chatre
2024-05-15 22:23 ` [PATCH v18 15/17] x86/resctrl: Fix RMID reading sanity check for Sub-NUMA (SNC) mode Tony Luck
2024-05-16  8:59   ` Maciej Wieczor-Retman
2024-05-22 21:25   ` Reinette Chatre
2024-05-22 23:47     ` Tony Luck
2024-05-23 17:03       ` Reinette Chatre
2024-05-15 22:23 ` [PATCH v18 16/17] x86/resctrl: Sub NUMA Cluster detection and enable Tony Luck
2024-05-22 21:26   ` Reinette Chatre
2024-05-15 22:23 ` [PATCH v18 17/17] x86/resctrl: Update documentation with Sub-NUMA cluster changes Tony Luck
2024-05-16  8:57   ` Maciej Wieczor-Retman
2024-05-22 21:27   ` Reinette Chatre
2024-05-16  9:28 ` [PATCH v18 00/17] Add support for Sub-NUMA cluster (SNC) systems Maciej Wieczor-Retman
2024-05-16 15:52   ` Luck, Tony

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=013c9532-cacf-4604-b1d9-e90fdc80e7dd@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=Dave.Martin@arm.com \
    --cc=babu.moger@amd.com \
    --cc=dfustini@baylibre.com \
    --cc=fenghua.yu@intel.com \
    --cc=james.morse@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=patches@lists.linux.dev \
    --cc=peternewman@google.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox