Re: [PATCH v7 2/5] riscv_cbqri: resctrl: Add cache allocation via capacity block mask

[Luck, Tony]

On Thu, Sep 17, 2026 at 08:37:43AM -0700, Reinette Chatre wrote:
> Hi Drew,
> 
> On 9/1/26 3:31 PM, Drew Fustini wrote:
> > resctrl exposes a single cap set per rid, so when more than one capacity
> > controller backs a cache level they must agree on those caps. A level
> > whose controllers disagree is left unexposed. Other levels are
> > unaffected.
> If I understand correctly, while attempting to translate to resctrl terms,
> this means that a cache resource with several domains may support different
> capacity masks in the domains?
> 
> I believe the "single cap set per rid" you refer to is
> /sys/fs/resctrl/info/L3/cbm_mask and /sys/fs/resctrl/info/L2/cbm_mask that
> exposes a single capacity bitmask representing the maximum allocation.
> 
> As you know, resctrl is in the process of changing the way in which schema
> formats are described. The most recent PoC [1] added new bitmap description
> files but it kept a single value "max" file to describe the highest allocation
> possible for a bitmap schema.
> 
> To support asymmetrical cache instances it looks like changing the interface
> to describe the maximum per domain (instead of one global value) could address
> the gap?
> 
> For example, if there is a hypothetical system with two L2 cache instances, one
> with a 0xFF max CBM and the other with a 0XF max CBM then resctrl could expose it
> as:

That sounds like the not-at-all-hypothetical Intel hybrid client parts
where P-core and E-core have different L2 masks.

> 
> 	# cat /sys/fs/resctrl/info/L2/schemata/L2/max
> 	0=ff;1=f
> 
> The schemata file currently and will continue to display the allocations per domain.
> 
> resctrl will need more changes to support different CBM per domain internally and
> until then all these CBMs will be the same, but adding this change to user interface now
> may set resctrl up to support these systems in the future?

I think Fenghua once worked on patches to support this. But I don't
think they were every posted to LKML. One of the open issues at the time
was how to handle the info/L2/cbm_mask file.

> Reinette
> 
> [1] https://lore.kernel.org/lkml/d258a32f-12d5-464d-abe9-4720fb3e44b3@xxxxxxxxx/

-Tony