lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f53c085-6bc2-4b5f-936c-5ee0d3b0648d@arm.com>
Date: Thu, 15 Jan 2026 16:02:47 +0000
From: Ben Horgan <ben.horgan@....com>
To: "Shaopeng Tan (Fujitsu)" <tan.shaopeng@...itsu.com>
Cc: "amitsinght@...vell.com" <amitsinght@...vell.com>,
 "baisheng.gao@...soc.com" <baisheng.gao@...soc.com>,
 "baolin.wang@...ux.alibaba.com" <baolin.wang@...ux.alibaba.com>,
 "carl@...amperecomputing.com" <carl@...amperecomputing.com>,
 "dave.martin@....com" <dave.martin@....com>,
 "david@...nel.org" <david@...nel.org>,
 "dfustini@...libre.com" <dfustini@...libre.com>,
 "fenghuay@...dia.com" <fenghuay@...dia.com>,
 "gshan@...hat.com" <gshan@...hat.com>,
 "james.morse@....com" <james.morse@....com>,
 "jonathan.cameron@...wei.com" <jonathan.cameron@...wei.com>,
 "kobak@...dia.com" <kobak@...dia.com>,
 "lcherian@...vell.com" <lcherian@...vell.com>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "peternewman@...gle.com" <peternewman@...gle.com>,
 "punit.agrawal@....qualcomm.com" <punit.agrawal@....qualcomm.com>,
 "quic_jiles@...cinc.com" <quic_jiles@...cinc.com>,
 "reinette.chatre@...el.com" <reinette.chatre@...el.com>,
 "rohit.mathew@....com" <rohit.mathew@....com>,
 "scott@...amperecomputing.com" <scott@...amperecomputing.com>,
 "sdonthineni@...dia.com" <sdonthineni@...dia.com>,
 "xhao@...ux.alibaba.com" <xhao@...ux.alibaba.com>,
 "catalin.marinas@....com" <catalin.marinas@....com>,
 "will@...nel.org" <will@...nel.org>, "corbet@....net" <corbet@....net>,
 "maz@...nel.org" <maz@...nel.org>, "oupton@...nel.org" <oupton@...nel.org>,
 "joey.gouly@....com" <joey.gouly@....com>,
 "suzuki.poulose@....com" <suzuki.poulose@....com>,
 "kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>
Subject: Re: [PATCH v3 37/47] arm_mpam: resctrl: Update the rmid reallocation
 limit

Hi Shaopeng,

On 1/15/26 10:05, Shaopeng Tan (Fujitsu) wrote:
> Hello Ben,
> 
>> From: James Morse <james.morse@....com>
>>
>> resctrl's limbo code needs to be told when the data left in a cache is
>> small enough for the partid+pmg value to be re-allocated.
>>
>> x86 uses the cache size divided by the number of rmid users the cache may
>> have. Do the same, but for the smallest cache, and with the number of
>> partid-and-pmg users.
>>
>> Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>
>> Signed-off-by: James Morse <james.morse@....com>
>> Signed-off-by: Ben Horgan <ben.horgan@....com>
>> ---
>> Changes since v2:
>> Move waiting for cache info into it's own patch
>> ---
>>  drivers/resctrl/mpam_resctrl.c | 35 ++++++++++++++++++++++++++++++++++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
>> index 5adc78f9c96f..a6be3ce84241 100644
>> --- a/drivers/resctrl/mpam_resctrl.c
>> +++ b/drivers/resctrl/mpam_resctrl.c
>> @@ -561,6 +561,38 @@ void resctrl_arch_reset_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,
>>          reset_mon_cdp_safe(mon, mon_comp, USE_PRE_ALLOCATED, closid, rmid);
>>  }
>>  
>> +/*
>> + * The rmid realloc threshold should be for the smallest cache exposed to
>> + * resctrl.
>> + */
>> +static int update_rmid_limits(struct mpam_class *class)
>> +{
>> +       u32 num_unique_pmg = resctrl_arch_system_num_rmid_idx();
>> +       struct mpam_props *cprops = &class->props;
>> +       struct cacheinfo *ci;
>> +
>> +       lockdep_assert_cpus_held();
>> +
>> +       /* Assume cache levels are the same size for all CPUs... */
>> +       ci = get_cpu_cacheinfo_level(smp_processor_id(), class->level);
>> +       if (!ci || ci->size == 0) {
>> +               pr_debug("Could not read cache size for class %u\n",
>> +                        class->level);
>> +               return -EINVAL;
>> +       }
>> +
>> +       if (!mpam_has_feature(mpam_feat_msmon_csu, cprops))
>> +               return 0;
> 
> Shouldn't it be return -EOPNOTSUPP;?

The intent of returning 0 here is that if csu is not supported on this
class then there is nothing to do and hence no error.

> 
> However, before the function update_rmid_limits() is called, there is a check: if (cache_has_usable_csu(class) && topology_matches_l3(class)).
> cache_has_usable_csu(class) already contains an identical check. Therefore, I think it's safe to remove this redundant one.

Yes, the check is redundant and can be removed. (If it were to stay it
should be moved to be before call get_cpu_cacheinfo_level() call so that
wouldn't give spurious errors for non-cache cpus.)

Thanks,

Ben


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ