public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: babu.moger@amd.com
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	Reinette Chatre <reinette.chatre@intel.com>,
	Peter Newman <peternewman@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	x86@kernel.org, James Morse <james.morse@arm.com>,
	Jamie Iles <quic_jiles@quicinc.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	"Shaopeng Tan (Fujitsu)" <tan.shaopeng@fujitsu.com>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	patches@lists.linux.dev
Subject: Re: [PATCH v9 3/9] x86/resctrl: Modify update_mba_bw() to use per ctrl_mon group event
Date: Mon, 18 Nov 2024 16:01:13 -0800	[thread overview]
Message-ID: <ZzvVSamxTo9QSWBU@agluck-desk3> (raw)
In-Reply-To: <b4b31f4f-7f09-4ee3-9373-6ffe5ea859a6@amd.com>

On Fri, Nov 15, 2024 at 10:21:01AM -0600, Moger, Babu wrote:
> Hi Tony,

Thanks for looking at this patch.

> 
> On 11/13/2024 6:17 PM, Tony Luck wrote:
> > Instead of hard-coding the memory bandwidth local event as the
> > input to the mba_sc feedback look, use the event that the user
> > configured for each ctrl_mon group.
> > 
> > Signed-off-by: Tony Luck <tony.luck@intel.com>
> > ---
> >   arch/x86/kernel/cpu/resctrl/monitor.c | 23 ++++++++++++++++++-----
> >   1 file changed, 18 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
> > index 7ef1a293cc13..2176e355e864 100644
> > --- a/arch/x86/kernel/cpu/resctrl/monitor.c
> > +++ b/arch/x86/kernel/cpu/resctrl/monitor.c
> > @@ -752,20 +752,31 @@ static void update_mba_bw(struct rdtgroup *rgrp, struct rdt_mon_domain *dom_mbm)
> >   	u32 closid, rmid, cur_msr_val, new_msr_val;
> >   	struct mbm_state *pmbm_data, *cmbm_data;
> >   	struct rdt_ctrl_domain *dom_mba;
> > +	enum resctrl_event_id evt_id;
> >   	struct rdt_resource *r_mba;
> > -	u32 cur_bw, user_bw, idx;
> >   	struct list_head *head;
> >   	struct rdtgroup *entry;
> > +	u32 cur_bw, user_bw;
> > -	if (!is_mbm_local_enabled())
> > +	if (!is_mbm_enabled())
> >   		return;
> >   	r_mba = &rdt_resources_all[RDT_RESOURCE_MBA].r_resctrl;
> > +	evt_id = rgrp->mba_mbps_event;
> > +
> > +	if (WARN_ON_ONCE(!is_mbm_event(evt_id)))
> > +		return;
> 
> I feel this check is enough.
> 
> > +	if (WARN_ON_ONCE(evt_id == QOS_L3_MBM_LOCAL_EVENT_ID && !is_mbm_local_enabled()))
> > +		return;
> > +	if (WARN_ON_ONCE(evt_id == QOS_L3_MBM_TOTAL_EVENT_ID && !is_mbm_total_enabled()))
> > +		return;
> 
> These two checks are not necessary.  You are already validating it while
> initializing(in patch 7).

I added this in response to a comment on v7 from Reinette that evt_id
wasn't properly validated here - in conjuction with the change a few
lines earlier that relaxed the check for is_mbm_local_enabled() to
just is_mbm_enabled().

See: https://lore.kernel.org/r/bb30835f-5be9-44b4-8544-2f528e7fc573@intel.com

In theory all of these tests could be dropped. As you point out the
sanity checks are done higher in the call sequence. But some folks
like the "belt and braces" approach to such sanity checks.

> > +
> >   	closid = rgrp->closid;
> >   	rmid = rgrp->mon.rmid;
> > -	idx = resctrl_arch_rmid_idx_encode(closid, rmid);
> > -	pmbm_data = &dom_mbm->mbm_local[idx];
> > +	pmbm_data = get_mbm_state(dom_mbm, closid, rmid, evt_id);
> > +	if (WARN_ON_ONCE(!pmbm_data))
> > +		return;
> >   	dom_mba = get_ctrl_domain_from_cpu(smp_processor_id(), r_mba);
> >   	if (!dom_mba) {
> > @@ -784,7 +795,9 @@ static void update_mba_bw(struct rdtgroup *rgrp, struct rdt_mon_domain *dom_mbm)
> >   	 */
> >   	head = &rgrp->mon.crdtgrp_list;
> >   	list_for_each_entry(entry, head, mon.crdtgrp_list) {
> > -		cmbm_data = &dom_mbm->mbm_local[entry->mon.rmid];
> > +		cmbm_data = get_mbm_state(dom_mbm, entry->closid, entry->mon.rmid, evt_id);
> > +		if (WARN_ON_ONCE(!cmbm_data))
> > +			return;
> >   		cur_bw += cmbm_data->prev_bw;
> >   	}
> 
> -- 
> - Babu Moger

-Tony

  reply	other threads:[~2024-11-19  0:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-14  0:17 [PATCH v9 0/9] x86/resctrl: mba_MBps enhancement Tony Luck
2024-11-14  0:17 ` [PATCH v9 1/9] x86/resctrl: Introduce resctrl_file_fflags_init() to initialize fflags Tony Luck
2024-11-15 16:19   ` Moger, Babu
2024-11-20  0:38   ` Reinette Chatre
2024-11-21 17:21     ` Luck, Tony
2024-11-14  0:17 ` [PATCH v9 2/9] x86/resctrl: Prepare for per-ctrl_mon group mba_MBps control Tony Luck
2024-11-15 16:20   ` Moger, Babu
2024-11-18 23:47     ` Luck, Tony
2024-11-20  1:08   ` Reinette Chatre
2024-11-21 17:33     ` Luck, Tony
2024-11-22 21:33       ` Reinette Chatre
2024-11-14  0:17 ` [PATCH v9 3/9] x86/resctrl: Modify update_mba_bw() to use per ctrl_mon group event Tony Luck
2024-11-15 16:21   ` Moger, Babu
2024-11-19  0:01     ` Luck, Tony [this message]
2024-11-19  0:51       ` Reinette Chatre
2024-11-19  1:44         ` Luck, Tony
2024-11-19 17:36           ` Reinette Chatre
2024-11-20  3:39   ` Reinette Chatre
2024-11-14  0:17 ` [PATCH v9 4/9] x86/resctrl: Compute memory bandwidth for all supported events Tony Luck
2024-11-15 13:53   ` Peter Newman
2024-11-15 16:59     ` Luck, Tony
2024-11-20  3:45   ` Reinette Chatre
2024-11-21 17:36     ` Luck, Tony
2024-11-14  0:17 ` [PATCH v9 5/9] x86/resctrl: Relax checks for mba_MBps mount option Tony Luck
2024-11-20  3:54   ` Reinette Chatre
2024-11-21 17:39     ` Luck, Tony
2024-11-14  0:17 ` [PATCH v9 6/9] x86/resctrl: Add "mba_MBps_event" file to ctrl_mon directories Tony Luck
2024-11-20  4:03   ` Reinette Chatre
2024-11-21 17:42     ` Luck, Tony
2024-11-14  0:17 ` [PATCH v9 7/9] x86/resctrl: Add write option to "mba_MBps_event" file Tony Luck
2024-11-14  0:17 ` [PATCH v9 8/9] x86/resctrl: Make mba_sc use total bandwidth if local is not supported Tony Luck
2024-11-14  0:17 ` [PATCH v9 9/9] x86/resctrl: Document the new "mba_MBps_event" file Tony Luck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZzvVSamxTo9QSWBU@agluck-desk3 \
    --to=tony.luck@intel.com \
    --cc=babu.moger@amd.com \
    --cc=corbet@lwn.net \
    --cc=fenghua.yu@intel.com \
    --cc=james.morse@arm.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=peternewman@google.com \
    --cc=quic_jiles@quicinc.com \
    --cc=rdunlap@infradead.org \
    --cc=reinette.chatre@intel.com \
    --cc=tan.shaopeng@fujitsu.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox