[lkml]   [2018]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/6] x86/intel_rdt/mba_sc: Add documentation for MBA software controller

On Tue, 3 Apr 2018, Thomas Gleixner wrote:

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

That is true. The default values only put it to a very high bandwidth which
means user gets to use everything. There seems no other way other than
caliberating to know the actual max bandwidth in bytes. That could be a better
value to have as default so admin knows the limit. I will explore if there is
a way to calculate the same without caliberating.


> Thanks,
> tglx

 \ /
  Last update: 2018-04-03 20:52    [W:0.150 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site