From: Reinette Chatre <reinette.chatre@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Fenghua Yu <fenghuay@nvidia.com>,
Maciej Wieczor-Retman <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>, Chen Yu <yu.c.chen@intel.com>,
<x86@kernel.org>, <linux-kernel@vger.kernel.org>,
<patches@lists.linux.dev>
Subject: Re: [PATCH v10 02/28] x86/resctrl: Move L3 initialization into new helper function
Date: Mon, 22 Sep 2025 16:29:54 -0700 [thread overview]
Message-ID: <1bd224fd-bc80-41ad-aaa6-863a7604890c@intel.com> (raw)
In-Reply-To: <aM2cctuXS8NBLeJ5@agluck-desk3>
Hi Tony,
On 9/19/25 11:09 AM, Luck, Tony wrote:
> On Thu, Sep 18, 2025 at 02:49:05PM -0700, Reinette Chatre wrote:
>> Hi Tony,
>>
>> On 9/12/25 3:10 PM, Tony Luck wrote:
>>> All resctrl monitor events are associated with the L3 resource, but
>>> this is about to change.
>>
>> Please see Boris's feedback about changelogs in [1]. To address that,
>> please rework the changelogs to not have so much copy&pasted context
>> in patches.
>
> I understand that Boris doesn't want to see large amounts of text copied
> from the cover letter into each patch. But there is still a need to meet the
> "Describe your problem" requirement for a good commit message.
>
> Several of the prepatory patches in this series make changes to expand the
> capabilities of fs/resctrl to handle monitor events from resources other
> than RDT_RESOURCE_L3.
>
> Is a single short sentence repeated in several patches "too much"?
You are correct that "repetitive" is subjective and "too much" is not
deterministic. Yet, we received a clear message that repetitive boilerplate is
really annoying. To me, five of the first seven patches starting with the same sentence
is close if not firmly in the repetitive boilerplate category. I've already highlighted
that that sentence can just be dropped from patch #3 and looking ahead, also from
patch #7, without losing context. Those are simple changes and I believe the
changelogs can be further reworked to improve the context to be unique per patch.
On a high level: we received valuable information about expectations from
changelogs. While I agree this is subjective, I am not interested in probes to
determine what the tolerance for repetition is but instead I intend to just take
the feedback to heart and work towards avoiding repetition.
>>> To prepare for additional types of monitoring domains, move open coded L3
>>> resource monitoring domain initialization from domain_add_cpu_mon() into
>>> a new helper l3_mon_domain_setup() called by domain_add_cpu_mon().
>>>
>>> Signed-off-by: Tony Luck <tony.luck@intel.com>
>>> ---
...
.
>>
>>> + return;
>>> + }
>>> +
>>> + switch (r->rid) {
>>> + case RDT_RESOURCE_L3:
>>
>> Something like:
>> if (hdr) {
>> /* do resource specific CPU initialization here */
>> return;
>> }
>
> In this specific case the resource specific operation needs to happen
> on every CPU (it updates the per-CPU MSR_IA32_L3_QOS_EXT_CFG). So I
> think the code fragment needs to be:
>
> switch (r->rid) {
> case RDT_RESOURCE_L3:
> /* Update the mbm_assign_mode state for the CPU if supported */
> if (r->mon.mbm_cntr_assignable)
> resctrl_arch_mbm_cntr_assign_set_one(r);
> if (!hdr)
> l3_mon_domain_setup(cpu, id, r, add_pos);
> break;
>
ok. I think this will work for this specific initialization. I do not think this is
appropriate as a general pattern since the per-CPU initialization may be called with
and without a domain structure.
>>
>>> + l3_mon_domain_setup(cpu, id, r, add_pos);
>>> + break;
>>> + default:
>>> + pr_warn_once("Unknown resource rid=%d\n", r->rid);
>>> + break;
>>> + }
>>> +}
>>> +
Reinette
next prev parent reply other threads:[~2025-09-22 23:30 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-12 22:10 [PATCH v10 00/28] x86,fs/resctrl telemetry monitoring Tony Luck
2025-09-12 22:10 ` [PATCH v10 01/28] x86,fs/resctrl: Improve domain type checking Tony Luck
2025-09-12 22:10 ` [PATCH v10 02/28] x86/resctrl: Move L3 initialization into new helper function Tony Luck
2025-09-18 21:49 ` Reinette Chatre
2025-09-19 18:09 ` Luck, Tony
2025-09-22 23:29 ` Reinette Chatre [this message]
2025-09-23 10:09 ` Borislav Petkov
2025-09-12 22:10 ` [PATCH v10 03/28] x86,fs/resctrl: Refactor domain_remove_cpu_mon() ready for new domain types Tony Luck
2025-09-18 21:49 ` Reinette Chatre
2025-09-12 22:10 ` [PATCH v10 04/28] x86/resctrl: Clean up domain_remove_cpu_ctrl() Tony Luck
2025-09-12 22:10 ` [PATCH v10 05/28] x86,fs/resctrl: Use struct rdt_domain_hdr instead of struct rdt_mon_domain Tony Luck
2025-09-18 21:54 ` Reinette Chatre
2025-09-12 22:10 ` [PATCH v10 06/28] x86,fs/resctrl: Use struct rdt_domain_hdr when reading counters Tony Luck
2025-09-12 22:10 ` [PATCH v10 07/28] x86,fs/resctrl: Rename struct rdt_mon_domain and rdt_hw_mon_domain Tony Luck
2025-09-12 22:10 ` [PATCH v10 08/28] x86,fs/resctrl: Rename some L3 specific functions Tony Luck
2025-09-12 22:10 ` [PATCH v10 09/28] fs/resctrl: Make event details accessible to functions when reading events Tony Luck
2025-09-12 22:10 ` [PATCH v10 10/28] x86,fs/resctrl: Handle events that can be read from any CPU Tony Luck
2025-09-12 22:10 ` [PATCH v10 11/28] x86,fs/resctrl: Support binary fixed point event counters Tony Luck
2025-09-12 22:10 ` [PATCH v10 12/28] x86,fs/resctrl: Add an architectural hook called for each mount Tony Luck
2025-09-12 22:10 ` [PATCH v10 13/28] x86,fs/resctrl: Add and initialize rdt_resource for package scope monitor Tony Luck
2025-09-12 22:10 ` [PATCH v10 14/28] x86/resctrl: Discover hardware telemetry events Tony Luck
2025-09-12 22:10 ` [PATCH v10 15/28] x86,fs/resctrl: Fill in details of events for guid 0x26696143 and 0x26557651 Tony Luck
2025-09-12 22:10 ` [PATCH v10 16/28] x86,fs/resctrl: Add architectural event pointer Tony Luck
2025-09-12 22:10 ` [PATCH v10 17/28] x86/resctrl: Find and enable usable telemetry events Tony Luck
2025-09-12 22:10 ` [PATCH v10 18/28] x86/resctrl: Read " Tony Luck
2025-09-12 22:10 ` [PATCH v10 19/28] x86/resctrl: Handle domain creation/deletion for RDT_RESOURCE_PERF_PKG Tony Luck
2025-09-12 22:10 ` [PATCH v10 20/28] x86/resctrl: Add energy/perf choices to rdt boot option Tony Luck
2025-09-12 22:10 ` [PATCH v10 21/28] x86/resctrl: Handle number of RMIDs supported by telemetry resources Tony Luck
2025-09-12 22:10 ` [PATCH v10 22/28] fs/resctrl: Move allocation/free of closid_num_dirty_rmid[] Tony Luck
2025-09-12 22:10 ` [PATCH v10 23/28] fs,x86/resctrl: Compute number of RMIDs as minimum across resources Tony Luck
2025-09-12 22:10 ` [PATCH v10 24/28] fs/resctrl: Move RMID initialization to first mount Tony Luck
2025-09-12 22:10 ` [PATCH v10 25/28] x86/resctrl: Enable RDT_RESOURCE_PERF_PKG Tony Luck
2025-09-12 22:10 ` [PATCH v10 26/28] fs/resctrl: Provide interface to create architecture specific debugfs area Tony Luck
2025-09-12 22:10 ` [PATCH v10 27/28] x86/resctrl: Add debugfs files to show telemetry aggregator status Tony Luck
2025-09-12 22:10 ` [PATCH v10 28/28] x86,fs/resctrl: Update Documentation for package events Tony Luck
2025-09-15 15:21 ` 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=1bd224fd-bc80-41ad-aaa6-863a7604890c@intel.com \
--to=reinette.chatre@intel.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=dfustini@baylibre.com \
--cc=fenghuay@nvidia.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 \
--cc=yu.c.chen@intel.com \
/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