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 15:31:45 -0700 [thread overview]
Message-ID: <f326387d-9636-4377-b82f-10e8d335c6ff@intel.com> (raw)
In-Reply-To: <SJ1PR11MB6083C6A9DFFF58FE305A33F3FCF42@SJ1PR11MB6083.namprd11.prod.outlook.com>
Hi Tony,
On 5/23/24 2:25 PM, Luck, Tony wrote:
>>> 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.
>
> So (in arch/x86/kernel/cpu/resctrl/monitor.c)
>
> static int snc_nodes_per_l3_cache = 1;
>
> Set and use only in this (arch specific) file.
Since this series initializes this value in
arch/x86/kernel/cpu/resctrl/core.c it is not clear to
me from just this one line how you envision the changes.
Just to be clear ... when I refer to arch specific and
filesystem code I am considering how this series integrates with [1]
since that is the direction resctrl is headed in.
Being "arch specific" thus does not require that it be moved into
monitor.c - it could be added to arch/x86/kernel/cpu/resctrl/internal.h
where it can remain after the fs/arch split.
It will be very helpful if you view your series while taking
[1] into account. For example, when looking at [1] you will see that
mon_event_count() and __mon_event_count() are resctrl filesystem
functions. When you consider that it should be clear that adding
an arch specific get_node_rmid() between these functions will make
the arch/fs split more difficult.
Reinette
[1] https://lore.kernel.org/lkml/20240321165106.31602-1-james.morse@arm.com/
next prev parent reply other threads:[~2024-05-23 22:31 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
2024-05-23 21:25 ` Luck, Tony
2024-05-23 22:31 ` Reinette Chatre [this message]
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=f326387d-9636-4377-b82f-10e8d335c6ff@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