Re: [PATCH v6 5/9] x86/resctrl: Parse ACPI CMRC table

["Luck, Tony" <tony.luck@intel.com>]

On Wed, Aug 26, 2026 at 12:11:49AM +0800, Chen, Yu C wrote:
> Hi Reinette,
> 
> On 8/25/2026 11:39 PM, Reinette Chatre wrote:
> > Hi Chenyu,
> > 
> > On 8/25/26 2:19 AM, Chen, Yu C wrote:
> > > On 8/20/2026 7:06 AM, Reinette Chatre wrote:
> > > > On 7/25/26 2:23 AM, Chen Yu wrote:
> > > > Actually, looks like the original
> > > > MSR based scale obtained via CPUID.(EAX=0FH,ECX=1H) is 32 bits while this new scale value
> > > > from CMRC is 64 bits. The existing code can thus not accommodate the new values and need to
> > > > be updated?
> > > > 
> > > 
> > > Yes, the legacy CPUID reports it as 32 bits, while CMRC is declared as 64 bits.
> > > 
> > > In theory, we should change the scale type from unsigned int to u64 to accommodate
> > > both the legacy CPUID and CMRC. However, it seems unlikely that the scale would
> > > exceed 32 bits. If the scale were 32 bits, the L3 occupancy would be at least
> > > 2^32 − 1, which is about 4 GB. We have not yet seen platform with 4 GB of L3 cache.
> > > So perhaps we can keep erdt_scale as unsigned int for now IMO.
> > 
> > 
> > It sounds like you are saying that the spec you are enabling should not be using 64 bits for
> > this value. It is unexpected to me that work on enabling of a spec adds such constraint without
> > clear motivation. If you find that the spec is not correct then I think it would be better to have
> > it changed there instead of building what appears to be unsupported assumptions into resctrl.
> > 
> 
> OK, let me check with the team.

Looking at the RDT architecture spec that defines the CMRC table it
looks to me like the "CMT Counter Upscaling Factor" was made 8-bytes
just to round the table out to a whole number or quad-words.

This value represents the granularity of cache occupancy reporting.
The feature would be worthless if this was >=4GB no matter how large
the LLC cache may be in future generations.

If large values are a big concern then perhaps include a sanity check
in the code:

	if (cmrc->upscale >= SZ_4G)
		pr_warn(FW_BUG "insane CMRC upscale value 0x%llx\n", cmrc->upscale);
> 
> thanks,
> Chenyu

-Tony