From: Thomas Gleixner <tglx@linutronix.de>
To: Vikas Shivappa <vikas.shivappa@linux.intel.com>
Cc: vikas.shivappa@intel.com, tony.luck@intel.com,
ravi.v.shankar@intel.com, fenghua.yu@intel.com,
sai.praneeth.prakhya@intel.com, x86@kernel.org, hpa@zytor.com,
linux-kernel@vger.kernel.org, ak@linux.intel.com
Subject: Re: [PATCH 1/6] x86/intel_rdt/mba_sc: Add documentation for MBA software controller
Date: Tue, 3 Apr 2018 16:29:42 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1804031625150.2511@nanos.tec.linutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.21.1803302153280.1479@nanos.tec.linutronix.de>
On Tue, 3 Apr 2018, Thomas Gleixner wrote:
> On Thu, 29 Mar 2018, Vikas Shivappa wrote:
> You said above:
>
> > This may lead to confusion in scenarios below:
>
> Reading the blurb after that creates even more confusion than being
> helpful.
>
> First of all this information should not be under the section 'Memory
> bandwidth in MB/s'.
>
> Also please write bandwidth. The weird acronym b/w (band per width???) is
> really not increasing legibility.
>
> What you really want is a general section about memory bandwidth allocation
> where you explain the technical background in purely technical terms w/o
> fairy tale mode. Technical descriptions have to be factual and not
> 'could/may/would'.
>
> If I decode the above correctly then the current percentage based
> implementation was buggy from the very beginning in several ways.
>
> Now the obvious question which is in no way answered by the cover letter is
> why the current percentage based implementation cannot be fixed and we need
> some feedback driven magic to achieve that. I assume you spent some brain
> cycles on that question, so it would be really helpful if you shared that.
>
> If I understand it correctly then the problem is that the throttling
> mechanism is per core and affects the L2 external bandwidth.
>
> Is this really per core? What about hyper threads. Both threads have that
> MSR. How is that working?
>
> The L2 external bandwidth is higher than the L3 external bandwidth.
>
> Is there any information available from CPUID or whatever source which
> allows us to retrieve the bandwidth ratio or the absolute maximum
> bandwidth per level?
>
> What's also missing from your explanation is how that feedback loop behaves
> under different workloads.
>
> Is this assuming that the involved threads/cpus actually try to utilize
> the bandwidth completely?
>
> What happens if the threads/cpus are only using a small set because they
> are idle or their computations are mostly cache local and do not need
> external bandwidth? Looking at the implementation I don't see how that is
> taken into account.
Forgot to mention the following:
The proposed new interface has no upper limit. The existing percentage
based implementation has at least some notion of limit and scale; not
really helpful either because of the hardware implementation. but I
How is the poor admin supposed to configure that new thing without
knowing what the actual hardware limits are in the first place?
Thanks,
tglx
next prev parent reply other threads:[~2018-04-03 14:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-29 22:26 [PATCH RFC 0/6] Memory b/w allocation software controller Vikas Shivappa
2018-03-29 22:26 ` [PATCH 1/6] x86/intel_rdt/mba_sc: Add documentation for MBA " Vikas Shivappa
2018-04-03 9:46 ` Thomas Gleixner
2018-04-03 14:29 ` Thomas Gleixner [this message]
2018-04-03 18:49 ` Shivappa Vikas
2018-04-04 9:30 ` Thomas Gleixner
2018-04-03 18:45 ` Shivappa Vikas
2018-04-04 9:11 ` Thomas Gleixner
2018-04-04 18:56 ` Shivappa Vikas
2018-03-29 22:26 ` [PATCH 2/6] x86/intel_rdt/mba_sc: Add support to enable/disable via mount option Vikas Shivappa
2018-03-30 9:32 ` Thomas Gleixner
2018-03-30 17:19 ` Shivappa Vikas
2018-03-29 22:26 ` [PATCH 3/6] x86/intel_rdt/mba_sc: Add initialization support Vikas Shivappa
2018-04-03 9:52 ` Thomas Gleixner
2018-04-03 18:51 ` Shivappa Vikas
2018-03-29 22:26 ` [PATCH 4/6] x86/intel_rdt/mba_sc: Add schemata support Vikas Shivappa
2018-03-29 22:26 ` [PATCH 5/6] x86/intel_rdt/mba_sc: Add counting for MBA software controller Vikas Shivappa
2018-03-29 22:26 ` [PATCH 6/6] x86/intel_rdt/mba_sc: Add support to dynamically update the memory b/w Vikas Shivappa
2018-03-30 21:21 ` kbuild test robot
2018-03-31 1:37 ` kbuild test robot
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=alpine.DEB.2.21.1804031625150.2511@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=ak@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ravi.v.shankar@intel.com \
--cc=sai.praneeth.prakhya@intel.com \
--cc=tony.luck@intel.com \
--cc=vikas.shivappa@intel.com \
--cc=vikas.shivappa@linux.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;
as well as URLs for NNTP newsgroup(s).