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

[Chen, Yu C]

On 8/26/2026 12:38 AM, Luck, Tony wrote:
> > > > 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);

Got it. The upscale factor should not exceed 32 bits, and the major 
monitor value
should come from the 'counter' part. I'll add the above check in the 
next version.

thanks,
Chenyu