Re: [PATCH 1/6] x86/intel_rdt/mba_sc: Add documentation for MBA software controller

[Shivappa Vikas]

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,
Vikas

> Thanks,
>
> 	tglx