All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Vikas Shivappa <vikas.shivappa@linux.intel.com>
Cc: vikas.shivappa@intel.com, linux-kernel@vger.kernel.org,
	x86@kernel.org, hpa@zytor.com, mingo@kernel.org,
	peterz@infradead.org, ravi.v.shankar@intel.com,
	tony.luck@intel.com, fenghua.yu@intel.com,
	h.peter.anvin@intel.com
Subject: Re: [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w allocation user interface
Date: Mon, 16 Jan 2017 14:43:25 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1701161323140.3877@nanos> (raw)
In-Reply-To: <1484076788-25385-2-git-send-email-vikas.shivappa@linux.intel.com>

On Tue, 10 Jan 2017, Vikas Shivappa wrote:

> Memory b/w allocation is part of Intel RDT(resource director technology)
> which lets user control the amount of memory b/w (L2 external b/w) per
> thread. This is done programming MSR interfaces like cache allocation
> technology and other RDT features.
> This patch adds documentation for Memory b/w allocation interface usage.

Sigh. I told you how often that 'This patch' is crap. We already know that
this is a patch. Read and finally act according to
Documentation/process/SubmittingPatches

> +Memory b/w throttle

Can we please spell out Bandwidth at least once? b/w can mean anything
(black/white, both ways ...)

> +-------------------
> +For Memory b/w resource, the portion of total memory b/w the user can
> +restrict or 'throttle by' is indicated by the thrtl_by values.
> +
> +Throttle by values could be linear scale or non-linear scale.  In linear
> +scale a thrtl_by value of say 20 would throttle the memory b/w by 20%
> +allowing only 80% max b/w. In nonlinear scale currently SDM specifies
> +throttle values in 2^n values. However the h/w does not guarantee a
> +specific curve for the amount of memory b/w that is actually throttled.
> +But for any thrtl_by value x > y, its guaranteed that x would throttle
> +more b/w than y.  The info directory specifies the max thrtl_by value
> +and thrtl_by granularity.

This interface is really crap. The natural way to express it is:

     Requested Bandwidth = X %

i.e. 100% is unthrottled.

The info file should tell the minimum bandwidth,the granularity value and
the scale mode.

The actual programming should just take a bandwidth percentage value
between 0 and 100. The written value is adjusted by the write function to
the granularity and minimum bandwidth, so a subsequent readout will tell
the effective value.

That's important because that allows scripts to work independent of the
actual hardware implementation with default bandwidth configurations and
then allows the user/admin to readout the effective values on a particular
machine. If someone wants to adjust them machine specific, that's possible
as well.

Aside of that this documentation should contain some information about the
limitations of that bandwidth control, i.e. the fact that this is a core
specific mechanism and using a high bandwidth and a low bandwidth setting
on two threads sharing a core will throttle the high bandwidth thread
inadvertently. That's really important to mention in the documentation
because that's going to bring interesting surprises for users.

Thanks,

	tglx

  reply	other threads:[~2017-01-16 13:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-10 19:33 [PATCH 0/8 V1] x86/intel_rdt: Memory b/w Allocation support Vikas Shivappa
2017-01-10 19:33 ` [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w allocation user interface Vikas Shivappa
2017-01-16 13:43   ` Thomas Gleixner [this message]
2017-01-18  0:51     ` Shivappa Vikas
2017-01-18  9:01       ` Thomas Gleixner
2017-01-23 18:57         ` Shivappa Vikas
2017-01-23 19:01           ` Thomas Gleixner
2017-01-24 22:10             ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 2/8] x86/intel_rdt/mba: Generalize the naming to get ready for MBA Vikas Shivappa
2017-01-16 13:45   ` Thomas Gleixner
2017-01-10 19:33 ` [PATCH 3/8] x86/intel_rdt/mba: Improvements to handle more RDT resources like MBA Vikas Shivappa
2017-01-16 13:54   ` Thomas Gleixner
2017-01-18  0:53     ` Shivappa Vikas
2017-01-18  9:05       ` Thomas Gleixner
2017-01-10 19:33 ` [PATCH 4/8] x86/intel_rdt/mba: Memory b/w allocation feature detect Vikas Shivappa
2017-01-16 13:59   ` Thomas Gleixner
2017-01-16 14:41     ` Peter Zijlstra
2017-01-16 16:16       ` Thomas Gleixner
2017-01-10 19:33 ` [PATCH 5/8] x86/intel_rct/mba: Add MBA structures and initialize MBA Vikas Shivappa
2017-01-16 14:06   ` Thomas Gleixner
2017-01-18  0:56     ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 6/8] x86/intel_rdt/mba: Add info directory files for MBA Vikas Shivappa
2017-01-16 14:14   ` Thomas Gleixner
2017-01-18  1:02     ` Shivappa Vikas
2017-01-18  9:08       ` Thomas Gleixner
2017-01-23 19:45         ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 7/8] x86/intel_rdt/mba: Add schemata file support " Vikas Shivappa
2017-01-16 16:07   ` Thomas Gleixner
2017-01-18  1:03     ` Shivappa Vikas
2017-01-10 19:33 ` [PATCH 8/8] x86/intel_rdt: rmdir,umount and hotcpu updates " Vikas Shivappa
2017-01-16 16:13   ` Thomas Gleixner
2017-01-23 20:18     ` Shivappa Vikas

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.20.1701161323140.3877@nanos \
    --to=tglx@linutronix.de \
    --cc=fenghua.yu@intel.com \
    --cc=h.peter.anvin@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.