Re: [PATCH 1/5] fs/resctrl: Drop support for different bandwidth delay mappings

[Chen, Yu C]

On 9/4/2026 11:50 PM, Reinette Chatre wrote:
> Hi Chenyu,
>
> On 9/3/26 8:33 PM, Chen Yu wrote:
> > On Thu, Sep 03, 2026 at 09:57:03AM -0700, Reinette Chatre wrote:
> > >   
> > > -/*
> > > - * Map the memory b/w percentage value to delay values
> > > - * that can be written to QOS_MSRs.
> > > - * There are currently no SKUs which support non linear delay values.
> > > - */
> > > -static u32 delay_bw_map(unsigned long bw, struct rdt_resource *r)
> > > -{
> > > -	if (r->membw.delay_linear)
> > > -		return MAX_MBA_BW - bw;
> > > -
> > > -	pr_warn_once("Non Linear delay-bw map not supported but queried\n");
> > > -	return MAX_MBA_BW;
> > > -}
> > > -
> > >   static void mba_wrmsr_intel(struct msr_param *m)
> > >   {
> > >   	struct rdt_hw_ctrl_domain *hw_dom = resctrl_to_arch_ctrl_dom(m->dom);
> > >   	struct rdt_hw_resource *hw_res = resctrl_to_arch_res(m->res);
> > >   	unsigned int i;
> > >   
> > > -	/*  Write the delay values for mba. */
> > > +	if (!m->res->membw.delay_linear) {
> > > +		pr_warn_once("Non-linear bandwidth delay not supported\n");
> > > +		return;
> >
> > Previously if linear delay is not supported, we still write MAX_MBA_BW
> > to MSR, and here we return with MSR untouched, this should be the expected
> > behavior?
>
> I believe so, yes. Two reasons:
> a) This is not a supported scenario. This code path should never execute
>     and already complains loudly if encountered.
> b) In the unlikely case that this unsupported scenario is encountered I
>     find leaving the hardware as-is to be the safer option.
>
> > Besides, in patch 2, __get_mem_config_intel() returns false for
> > non-linear-delay platform thus MB resource's alloc_capable is false,
> > do we still need to do the linear check in mba_wrmsr_intel() in patch 1
> > as the code path will not be triggered?
>
> You are right that the check is not required. I view this check more like
> why we use "lockdep_assert_held()". More specifically, it uses the code to
> document the requirements instead of comments. For Intel this is valuable
> since the transition to controls and their flags means that when a developer
> builds on the new resctrl capabilities to initialize multiple controls it is
> required for *each* control to have the "this scalar is linear" flag set. This
> test makes that requirement clear.

Got it, thanks for the explanation, this makes sense to me.

Reviewed-by: Chen Yu <yu.c.chen@xxxxxxxxx>

thanks,
Chenyu