lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <MW3PR12MB45530F4E7781F0ED5928C0E895329@MW3PR12MB4553.namprd12.prod.outlook.com>
Date:   Fri, 28 Oct 2022 15:16:33 +0000
From:   "Moger, Babu" <Babu.Moger@....com>
To:     Reinette Chatre <reinette.chatre@...el.com>,
        "corbet@....net" <corbet@....net>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>
CC:     "fenghua.yu@...el.com" <fenghua.yu@...el.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "paulmck@...nel.org" <paulmck@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "quic_neeraju@...cinc.com" <quic_neeraju@...cinc.com>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "damien.lemoal@...nsource.wdc.com" <damien.lemoal@...nsource.wdc.com>,
        "songmuchun@...edance.com" <songmuchun@...edance.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "jpoimboe@...nel.org" <jpoimboe@...nel.org>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "chang.seok.bae@...el.com" <chang.seok.bae@...el.com>,
        "pawan.kumar.gupta@...ux.intel.com" 
        <pawan.kumar.gupta@...ux.intel.com>,
        "jmattson@...gle.com" <jmattson@...gle.com>,
        "daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
        "Das1, Sandipan" <Sandipan.Das@....com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "james.morse@....com" <james.morse@....com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "bagasdotme@...il.com" <bagasdotme@...il.com>,
        "eranian@...gle.com" <eranian@...gle.com>
Subject: RE: [PATCH v7 05/12] x86/resctrl: Detect and configure Slow Memory
 Bandwidth allocation

[AMD Official Use Only - General]

Hi Reinette,

> -----Original Message-----
> From: Reinette Chatre <reinette.chatre@...el.com>
> Sent: Thursday, October 27, 2022 1:38 PM
> To: Moger, Babu <Babu.Moger@....com>; corbet@....net;
> tglx@...utronix.de; mingo@...hat.com; bp@...en8.de
> Cc: fenghua.yu@...el.com; dave.hansen@...ux.intel.com; x86@...nel.org;
> hpa@...or.com; paulmck@...nel.org; akpm@...ux-foundation.org;
> quic_neeraju@...cinc.com; rdunlap@...radead.org;
> damien.lemoal@...nsource.wdc.com; songmuchun@...edance.com;
> peterz@...radead.org; jpoimboe@...nel.org; pbonzini@...hat.com;
> chang.seok.bae@...el.com; pawan.kumar.gupta@...ux.intel.com;
> jmattson@...gle.com; daniel.sneddon@...ux.intel.com; Das1, Sandipan
> <Sandipan.Das@....com>; tony.luck@...el.com; james.morse@....com;
> linux-doc@...r.kernel.org; linux-kernel@...r.kernel.org;
> bagasdotme@...il.com; eranian@...gle.com
> Subject: Re: [PATCH v7 05/12] x86/resctrl: Detect and configure Slow Memory
> Bandwidth allocation
> 
> Hi Babu,
> 
> On 10/27/2022 8:30 AM, Moger, Babu wrote:
> > On 10/26/22 15:23, Reinette Chatre wrote:
> >> On 10/26/2022 12:07 PM, Moger, Babu wrote:
> >>> On 10/25/22 18:43, Reinette Chatre wrote:
> >>>> On 10/17/2022 3:26 PM, Babu Moger wrote:
> >>>>
> >>>> ...
> >>>>
> >>>>> @@ -2845,7 +2846,8 @@ static int rdtgroup_init_alloc(struct
> >>>>> rdtgroup *rdtgrp)
> >>>>>
> >>>>>  	list_for_each_entry(s, &resctrl_schema_all, list) {
> >>>>>  		r = s->res;
> >>>>> -		if (r->rid == RDT_RESOURCE_MBA) {
> >>>>> +		if (r->rid == RDT_RESOURCE_MBA ||
> >>>>> +		    r->rid == RDT_RESOURCE_SMBA) {
> >>>>>  			rdtgroup_init_mba(r, rdtgrp->closid);
> >>>>>  			if (is_mba_sc(r))
> >>>>>  				continue;
> >>>> The above hunk and the ones that follow are unexpected.
> >>> I am thinking the above check is required, It is updating the
> >>> staged_config with default values. Right now, the default value for
> >>> SMBA is same as MBA default value. So, I used this code to initialize.
> >>>
> >>> Did I miss something?
> >> As I described in the following comments my concern is related to all
> >> the software controller code still executing for SMBA. Yes, in the
> >> above hunk SMBA would need (some of) rdtgroup_init_mba() ... but note
> >> that it contains software controller checks and in the above hunk its
> >> call is also followed by another software controller check.
> >>
> >> The software controller is just applicable to MBA and these checks
> >> have been isolated to the MBA resource. Using it for SMBA that does
> >> not support software controller at all is making the code harder to
> >> follow and sets this code up for future mistakes. I think it would
> >> make the code easier to understand if this is made very clear that
> >> software controller is not applicable to SMBA at all instead of repurposing
> these flows.
> >
> > Yes. Understood.  How about this? I feel this is much more cleaner.
> >
> > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> > b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> > index e5a48f05e787..d91a6a513681 100644
> > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> > @@ -2845,16 +2845,18 @@ static int rdtgroup_init_alloc(struct rdtgroup
> > *rdtgrp)
> >
> >         list_for_each_entry(s, &resctrl_schema_all, list) {
> >                 r = s->res;
> > -               if (r->rid == RDT_RESOURCE_MBA) {
> > +               if (r->rid == RDT_RESOURCE_MBA ||
> > +                   r->rid == RDT_RESOURCE_SMBA) {
> >                         rdtgroup_init_mba(r, rdtgrp->closid);
> > -                       if (is_mba_sc(r))
> > -                               continue;
> >                 } else {
> >                         ret = rdtgroup_init_cat(s, rdtgrp->closid);
> >                         if (ret < 0)
> >                                 return ret;
> >                 }
> >
> > +               if (is_mba_sc(r))
> > +                       continue;
> > +
> >                 ret = resctrl_arch_update_domains(r, rdtgrp->closid);
> >                 if (ret < 0) {
> >                         rdt_last_cmd_puts("Failed to initialize
> > allocations\n");
> >
> 
> I do not see how that move changes what is run in the SMBA case and it ignores
> the
> is_mba_sc() call within rdtgroup_init_mba(). How about making is_mba_sc()
> more robust in support of your original snippet?
> 
> Something like:
> 
> bool is_mba_sc(struct rdt_resource *r)
> {
> 	if (!r)
> 		return
> rdt_resources_all[RDT_RESOURCE_MBA].r_resctrl.membw.mba_sc;
> 
> 	if (r->rid != RDT_RESOURCE_MBA)
> 		return false;
> 
> 	return r->membw.mba_sc;
> }

Yes. Sure. That should work.
Thanks
Babu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ