linux-kernel - Re: [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w allocation user interface

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1701161323140.3877@nanos>
Date:   Mon, 16 Jan 2017 14:43:25 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Vikas Shivappa <vikas.shivappa@...ux.intel.com>
cc:     vikas.shivappa@...el.com, linux-kernel@...r.kernel.org,
        x86@...nel.org, hpa@...or.com, mingo@...nel.org,
        peterz@...radead.org, ravi.v.shankar@...el.com,
        tony.luck@...el.com, fenghua.yu@...el.com, h.peter.anvin@...el.com
Subject: Re: [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w
 allocation user interface

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