Message-ID: <aUXaPsCeikFVy6ra@agluck-desk3>
Date: Fri, 19 Dec 2025 15:05:34 -0800
From: "Luck, Tony" <tony.luck@...el.com>
To: Reinette Chatre <reinette.chatre@...el.com>
CC: Aaron Tomlin <atomlin@...mlin.com>, "Moger, Babu" <bmoger@....com>,
	"Dave.Martin@....com" <Dave.Martin@....com>, "james.morse@....com"
	<james.morse@....com>, "babu.moger@....com" <babu.moger@....com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com"
	<mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "sean@...e.io"
	<sean@...e.io>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] x86/resctrl: Add "*" shorthand to set minimum
 io_alloc CBM for all domains

On Fri, Dec 19, 2025 at 02:00:32PM -0800, Reinette Chatre wrote:
> Hi Tony,
> 
> On 12/19/25 12:42 PM, Luck, Tony wrote:
> > On Fri, Dec 19, 2025 at 10:28:32AM -0800, Reinette Chatre wrote:
> >> Hi Aaron and Tony,
> >>
> >> On 12/18/25 4:44 PM, Aaron Tomlin wrote:
> >>> On Thu, Dec 18, 2025 at 02:59:59PM -0800, Reinette Chatre wrote:
> >>>> If I remember correctly the idea was to limit this feature to io_alloc to
> >>>> avoid needing to deal with L2 asymmetric domains [1].
> >>>
> >>> Hi Reinette,
> >>>
> >>> You are quite right; I am in complete agreement with your assessment. The
> >>> primary intention behind limiting the scope to io_alloc was indeed to avoid
> >>> the complexities associated with L2 asymmetric domains.
> >>>
> >>> Are we all in alignment to focus this feature entirely on io_alloc for the
> >>> time being? If so, I will be pleased to prepare a follow-up series that
> >>
> >> From my side I am ok to limit this to io_alloc. Of course, this does not prevent
> >> cache allocation from supporting this syntax in the future.
> >>
> >> Tony: did you perhaps imply with examples in [2] that '*' only be supported by
> >> L3 and MB, not L2? Can it be guaranteed that L3 will never be asymmetric? Not that
> >> it is a blocker though, as discussed earlier there are ways [3] to support
> > 
> > I'd forgotten the L2 asymmetry issue. If we wanted to enable "*" more
> > generally, then resctrl would have to limit it to symmetric resources
> > or to allow setting values that work for all domains in an asymmetric
> > resource).  But that seems more complexity in the kernel for something
> > than can easily be handled in user space. E.g. to reset L3 to ffff
> > 
> > # sed -n -e '/L3:/s/\(=[0-9a-f][0-9a-f]*\)/=ffff/gp' schemata > schemata
> 
> ack. 
> 
> Can I interpret this as you being ok to limit support for '*' syntax to io_alloc (for now?)?
> As I understand the intended implementation discussed here will indeed just allow setting values
> that will work for all domains ... all or nothing. So, if L3 does become asymmetric along the
> way then the implementation does seem to remain reasonable. 

I still don't see a good reason for the kernel to handle any of this.

Having some resctrl control files accept wildcards while others don't
seems like a confusing interface. Is there something I'm missing that
makes io_alloc harder for users to handle than L3 or MB in schemata?

Babu's simpler implementation for io_alloc makes me more comfortable
with this. But I'm still unconvinced that wildcards must be handled
in kernel code.

> 
> >> '*' when domains may be asymmetric. That proposal is only reasonable if considering the
> >> feature as "let user set same CBM on all domains" that just happens to support the "reset
> >> to min" use case for L3 io_alloc. I assume even on asymmetric domains the min would be the
> >> same? If there is indeed a requirement to support "reset to defaults" for general cache
> >> allocation then this feature would not work for asymmetric domains as you highlighted in [4].
> > 
> >> Although, a "reset to defaults" for cache allocation use case may be better handled by
> >> removing and recreating the resource group since the defaults will take into account
> >> any exclusive allocations?
> > 
> > Removing the directory would free the RMID and allocate a new one when you
> > recreated it. Losing cache occupancy information completely, and disturbing
> > memory bandwidth monitoring. Also leaving the user to hunt down tasks
> > that were reassigned to the default CLOS and reassign them. So too many
> > side effects.
> 
> I agree. Even so, without knowing more details about use case it is difficult to reason about
> user space expectations here. This is regarding a "reset to defaults" use case that was raised in
> [4]. Did you raise that concern based on insights into requests from users to support this?
> I think we would need to create new syntax if resctrl needs to support such use case.

I don't have any requests from users.

> 
> Reinette
> 
> 
> >>
> >> Reinette
> >>
> >>
> >>> reflects this consensus once our wider discussion has concluded.
> >>>
> >>>>
> >>>> [1] https://lore.kernel.org/lkml/SJ1PR11MB60833A27A1B8057CDDFB1B2BFCCFA@SJ1PR11MB6083.namprd11.prod.outlook.com/
> >> [2] https://lore.kernel.org/all/SJ1PR11MB6083CCA2A7904E459B1AA35DFCA8A@SJ1PR11MB6083.namprd11.prod.outlook.com/
> >> [3] https://lore.kernel.org/lkml/f4a043d2-9cb0-41c9-a45d-31f96fd007d5@amd.com/
> >> [4] https://lore.kernel.org/lkml/SJ1PR11MB60836AB4270419338FBB4D1EFCCEA@SJ1PR11MB6083.namprd11.prod.outlook.com/
> > 
> > -Tony
> 

-Tony

Powered by blists - more mailing lists