[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1ea9cff4-e93d-4be8-bbe2-308fc05eb3d1@intel.com>
Date: Thu, 9 Oct 2025 14:46:07 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>
CC: Fenghua Yu <fenghuay@...dia.com>, "Wieczor-Retman, Maciej"
<maciej.wieczor-retman@...el.com>, Peter Newman <peternewman@...gle.com>,
James Morse <james.morse@....com>, Babu Moger <babu.moger@....com>, "Drew
Fustini" <dfustini@...libre.com>, Dave Martin <Dave.Martin@....com>, "Chen,
Yu C" <yu.c.chen@...el.com>, "x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: Re: [PATCH v11 20/31] fs/resctrl: Refactor Sub-NUMA Cluster (SNC) in
mkdir/rmdir code flow
Hi Tony,
On 10/9/25 2:31 PM, Luck, Tony wrote:
>>> There are only two places where SNC mode is checked in this way. The
>>> others rely on seeing that mon_data::sum is set, or that rr->hdr is
>>> NULL. So it seems like a very small improvement.
>>
>> This is not about SNC mode or not but instead about this code being L3
>> resource specific.
>>
>> I see the mon_data::sum and rr->hdr checks as supporting a separate
>> feature that was introduced to support SNC - it should not be used as
>> a check for SNC support even though it currently implies this due to SNC
>> being the only user. Could we not, hypothetically, even use these properties
>> in the region aware MBM work?
>>
>>> If we ever add a node scoped resource that isn't related to SNC, it
>>> would be needed at that point. But I'm not sure why hardware would
>>> ever do that.
>>
>> Right. This is not about just what is needed to enable this feature but
>> about making the code easy to follow for those that attempt to understand,
>> debug, and/or build on top.
>
> Reinette,
>
> Region aware MBM work will need to sum things to support legacy resctrl
> "mbm_total_bytes". But while SNC sums across domains that share the
> same cache id inside the same resource, we may be summing across
> different resources (assuming we go with separate resources per region)
> or summing across regions within a domain (if we bundle the regions into a new
> struct rdt_region_mon_domain).
>
> So __mon_event_count() will need to get additional refactoring and helper
> functions, and struct mon_data an additional field to say that this other
> "sum" function must be used.
>
I did not mean to imply that this can be supported without refactoring. It does
seem as though you agree that mon_data::sum may be used for something
other than SNC and thus that using mon_data::sum as a check for SNC is not ideal.
Reinette
Powered by blists - more mailing lists