public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: linux-kernel@vger.kernel.org, Tony Luck <tony.luck@intel.com>,
	James Morse <james.morse@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Jonathan Corbet <corbet@lwn.net>,
	x86@kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] fs/resctrl,x86/resctrl: Factor mba rounding to be per-arch
Date: Mon, 29 Sep 2025 17:10:43 +0100	[thread overview]
Message-ID: <aNqvg984pmj+otfF@e133380.arm.com> (raw)
In-Reply-To: <c91846ab-e08e-48e9-83bb-357eab4b9d87@intel.com>

Hi Reinette,

On Mon, Sep 29, 2025 at 08:38:13AM -0700, Reinette Chatre wrote:
> Hi Dave,
> 
> On 9/29/25 5:43 AM, Dave Martin wrote:

[...]

> > Generally, I agree, although I'm not sure whether that acronym belongs
> > in the MPAM-specific code.
> > 
> > For this patch, though, that's irrelevant.  I've changed it to "MBA"
> > as requested.
> > 
> 
> Thank you.

[...]

> >> I find "worst-case precision" a bit confusing, consider for example, what
> >> would "best-case precision" be? What do you think of "info/MB/bandwidth_gran gives
> >> the upper limit of these interval steps"? I believe this matches what you
> >> mentioned a couple of messages ago: "The available steps are no larger than this
> >> value."
> > 
> > Yes, that works.  "Worst case" implies a value judgement that smaller
> > steps are "better" then large steps, since the goal is control.
> > 
> > But your wording, to the effect that this is the largest (apparent)
> > step size, conveys all the needed information.
> 
> Thank you for considering it. My preference is for stating things succinctly
> and not leave too much for interpretation.

I find that it's not always easy to work out what information is
essential without the discussion... so I hope that didn't feel like a
waste of time!

> >> (and "per cent" -> "percent")
> > 
> > ( Note: https://en.wiktionary.org/wiki/per_cent )
> 
> Yes, in particular I note the "chiefly Commonwealth". I respect the differences
> in the English language and was easily convinced in earlier MPAM work to
> accept different spelling. I now regret doing so because after merge we now have a
> supposedly coherent resctrl codebase with inconsistent spelling that is unpleasant
> to encounter when reading the code and also complicates new work.
> 
> > (Though either is acceptable, the fused word has a more informal feel
> > to it for me.  Happy to change it -- though your rewording below gets
> > rid of it anyway.  (This word doesn't appear in resctrl.rst --
> > evertying is "percentage" etc.)

Sure, it's best not to have mixed-up conventions in the same document.

(With this one, I wasn't aware that there were regional differences at
all, so that was news to me...)

[...]

> >> I think putting together a couple of your proposals and statements while making the
> >> text more accurate may work:
> >>
> >> 	 "bandwidth_gran":
> >> 		The approximate granularity in which the memory bandwidth
> >>  		percentage is allocated. The allocated bandwidth percentage
> >> 		is rounded up to the next control step available on the
> >> 		hardware. The available hardware steps are no larger than
> >> 		this value.
> > 
> > That's better, thanks.  I'm happy to pick this up and reword the text
> > in both places along these lines.
> 
> Thank you very much. Please do feel free to rework.
> 
> > 
> >> I assume "available" is needed because, even though the steps are not larger
> >> than "bandwidth_gran", the steps may not be consistent across the "min_bandwidth"
> >> to 100% range?
> > 
> > Yes -- or, rather, the steps _look_ inconsistent because they are
> > rounded to exact percentages by the interface.
> > 
> > I don't think we expect the actual steps in the hardware to be
> > irregular.
> > 
> Thank you for clarifying.
> 
> Reinette

OK.

I'll tidy up the loose ends and repost once I've have a chance to re-
test.

Thanks for the review.

Cheers
---Dave

  reply	other threads:[~2025-09-29 16:10 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-02 16:24 [PATCH] fs/resctrl,x86/resctrl: Factor mba rounding to be per-arch Dave Martin
2025-09-12 22:19 ` Reinette Chatre
2025-09-22 14:39   ` Dave Martin
2025-09-23 17:27     ` Reinette Chatre
2025-09-25 12:46       ` Dave Martin
2025-09-25 20:53         ` Reinette Chatre
2025-09-25 21:35           ` Luck, Tony
2025-09-25 22:18             ` Reinette Chatre
2025-09-29 13:08               ` Dave Martin
2025-09-29 12:43           ` Dave Martin
2025-09-29 15:38             ` Reinette Chatre
2025-09-29 16:10               ` Dave Martin [this message]
2025-10-15 15:18     ` Dave Martin
2025-10-16 15:57       ` Reinette Chatre
2025-10-17 15:52         ` Dave Martin
2025-09-22 15:04 ` Dave Martin
2025-09-25 22:58   ` Luck, Tony
2025-09-29  9:19     ` Chen, Yu C
2025-09-29 14:13       ` Dave Martin
2025-09-29 16:23         ` Luck, Tony
2025-09-30 11:02           ` Chen, Yu C
2025-09-30 16:08             ` Luck, Tony
2025-09-30  4:43         ` Chen, Yu C
2025-09-30 15:55           ` Dave Martin
2025-10-01 12:13             ` Chen, Yu C
2025-10-02 15:40               ` Dave Martin
2025-10-02 16:43                 ` Luck, Tony
2025-09-29 13:56     ` Dave Martin
2025-09-29 16:09       ` Reinette Chatre
2025-09-30 15:40         ` Dave Martin
2025-10-10 16:48           ` Reinette Chatre
2025-10-11 17:15             ` Chen, Yu C
2025-10-13 15:01               ` Dave Martin
2025-10-13 14:36             ` Dave Martin
2025-10-14 22:55               ` Reinette Chatre
2025-10-15 15:47                 ` Dave Martin
2025-10-15 18:48                   ` Luck, Tony
2025-10-16 14:50                     ` Dave Martin
2025-10-16 16:31                   ` Reinette Chatre
2025-10-17 14:17                     ` Dave Martin
2025-10-17 15:59                       ` Reinette Chatre
2025-10-20 15:50                         ` Dave Martin
2025-10-20 16:31                           ` Luck, Tony
2025-10-21 14:37                             ` Dave Martin
2025-10-21 20:59                               ` Luck, Tony
2025-10-22 14:58                                 ` Dave Martin
2025-10-22 16:21                                   ` Luck, Tony
2025-10-23 14:04                                     ` Dave Martin
2025-09-29 16:37       ` Luck, Tony
2025-09-30 16:02         ` Dave Martin
2025-09-26 20:54   ` Reinette Chatre
2025-09-29 13:40     ` Dave Martin

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=aNqvg984pmj+otfF@e133380.arm.com \
    --to=dave.martin@arm.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=reinette.chatre@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.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