lkml.org 
[lkml]   [2017]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w allocation user interface


    On Mon, 16 Jan 2017, Thomas Gleixner wrote:

    > 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 wanted to do it this way which did seem more intuitive but the issue is with
    the non-linear scale which the hardware does not guarantee a particular
    percentage for a particular value. Or we don't know the curve for delay value vs.
    actual b/w throttled.

    ex: in non linear scale , the granularity is 2^n.
    Max : 512

    Say a value of 256 is not guaranteed to have 50% or even follow a curve where we
    can calculate the corresponding percentage.

    >
    > 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.

    Ok , will do.

    Thanks,
    Vikas

    That's really important to mention in the documentation
    > because that's going to bring interesting surprises for users.
    >
    > Thanks,
    >
    > tglx
    >
    >
    >
    >

    \
     
     \ /
      Last update: 2017-01-18 01:52    [W:4.258 / U:1.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site