Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1561189 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w  allocation user interface Shivappa Vikas <vikas.shivappa@intel.com> - 2017-01-18 02:00 +0100
    Re: [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w  allocation user interface Thomas Gleixner <tglx@linutronix.de> - 2017-01-18 11:00 +0100
      Re: [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w  allocation user interface Shivappa Vikas <vikas.shivappa@intel.com> - 2017-01-23 20:00 +0100
        Re: [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w  allocation user interface Thomas Gleixner <tglx@linutronix.de> - 2017-01-23 20:10 +0100
          Re: [PATCH 1/8] Documentation, x86: Documentation for Intel Mem b/w  allocation user interface Shivappa Vikas <vikas.shivappa@intel.com> - 2017-01-24 23:20 +0100

#1561189 — Re: [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
>
>
>
>

[toc] | [next] | [standalone]

#1561422

On Tue, 17 Jan 2017, Shivappa Vikas wrote:
> On Mon, 16 Jan 2017, Thomas Gleixner wrote:
> > 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.

The question is whether this non linear scale thing is just a first
implementation attempt and any sane hardware in the future will use the
percentage value (which is an approximation as well).

If that non-linear scale is not going to be prevalent, then we really can
live with the fallout of a particular CPU type.

If it's going to stay, then Intel should be able to provide simple tables
which give us the required information for a particular CPU model.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1565248

On Wed, 18 Jan 2017, Thomas Gleixner wrote:

> On Tue, 17 Jan 2017, Shivappa Vikas wrote:
>> On Mon, 16 Jan 2017, Thomas Gleixner wrote:
>>> 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.
>
> The question is whether this non linear scale thing is just a first
> implementation attempt and any sane hardware in the future will use the
> percentage value (which is an approximation as well).
>
> If that non-linear scale is not going to be prevalent, then we really can
> live with the fallout of a particular CPU type.
>
> If it's going to stay, then Intel should be able to provide simple tables
> which give us the required information for a particular CPU model.

By sample table - does this mean we can map a throttle value in non-linear 
scale to its percentage ?

Thanks,
Vikas

>
> Thanks,
>
> 	tglx
>

[toc] | [prev] | [next] | [standalone]

#1565249

On Mon, 23 Jan 2017, Shivappa Vikas wrote:
> On Wed, 18 Jan 2017, Thomas Gleixner wrote:
> > If it's going to stay, then Intel should be able to provide simple tables
> > which give us the required information for a particular CPU model.
> 
> By sample table - does this mean we can map a throttle value in non-linear
> scale to its percentage ?

Exactly. And that map should be provided by Intel simply because it's a
royal pain in the neck if users have to map random power of 2 values to
something useful. And of course every user has to do the same thing on
their own. That'd be more than silly.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1566200

On Mon, 23 Jan 2017, Thomas Gleixner wrote:

> On Mon, 23 Jan 2017, Shivappa Vikas wrote:
>> On Wed, 18 Jan 2017, Thomas Gleixner wrote:
>>> If it's going to stay, then Intel should be able to provide simple tables
>>> which give us the required information for a particular CPU model.
>>
>> By sample table - does this mean we can map a throttle value in non-linear
>> scale to its percentage ?
>
> Exactly. And that map should be provided by Intel simply because it's a
> royal pain in the neck if users have to map random power of 2 values to
> something useful. And of course every user has to do the same thing on
> their own. That'd be more than silly.

Ok. Right now we dont have this capability on any SKUs, so i will just do a call 
to say get_throttle_map() for non_linear scale and fail if there is a nonlinear 
scale and later we can update to API to actually return the map for SKUs that 
support it.

Thanks,
Vikas

>
> Thanks,
>
> 	tglx
>
>
>
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web