[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 01/15] docs: create Memory Bandwidth Allocation (MBA) feature document



On Wed, Aug 30, 2017 at 01:20:14PM +0800, Yi Sun wrote:
> Thanks a lot for the review comments!
> 
> On 17-08-29 12:46:49, Roger Pau Monn� wrote:
> > On Thu, Aug 24, 2017 at 09:14:35AM +0800, Yi Sun wrote:
> > Although I have to admit I don't really understand this interface,
> > wouldn't it be easier to specify the memory bandwidth allowed
> > per-domain, rather the amount of bandwidth removed?
> > 
> > Using your approach the user has to first get the total bandwidth, and
> > then subtract the removed bandwidth in order to know the remaining
> > bandwidth for a domain.
> > 
> The HW only provides throttling set method to control the bandwidth. So, I
> think it is straightforward to set throttling in tools layer. The 
> 'psr-mba-set'
> is designed as a simple command to set what HW needs.
> 
> Also, mentioned by SDM, "The throttling values exposed by MBA are approximate,
> and are calibrated to specific traffic patterns.". So, it is hard to provide
> exact bandwidth control in 'psr-mba-set'.

OK, I think I will wait until I see the example explained in order to
express my opinion on the proposed toolstack interface.

> > Also, IMHO you should provide a command to print the max throttling,
> 
> The 'psr-hwinfo' can show the max throttling. Because it is part of MBA HW 
> info.
> 
> > remember that from Xen's PoV Dom0 is just another domain, and the
> > CPUID values reported to Dom0 don't need to be the same as found on
> > bare metal.
> > 
> But the CPUID values got through 'psr' commands should be ones found on bare
> metal, right? Because these commands directly get the values from hypervisor
> through domctl/sysctl.

Yes, if they are provided by the hypervisor (ie: cpuid instruction is
executed in Xen, not Dom0).

> > > +     if the MBA_MAX value is 90, the input precision is 10%. Values not 
> > > an even
> > > +     multiple of the precision (e.g., 12%) will be rounded down (e.g., 
> > > to 10%
> > > +     delay applied) by HW automatically.
> > > +
> > > +     Non-linear mode: input delay values are powers-of-two from zero to 
> > > the
> > > +     MBA_MAX value from CPUID. In this case any values not a power of 
> > > two will
> > > +     be rounded down the next nearest power of two by HW automatically.
> > > +
> > > +# Technical details
> > > +
> > > +MBA is a member of Intel PSR features, it shares the base PSR 
> > > infrastructure
> > > +in Xen.
> > > +
> > > +## Hardware perspective
> > > +
> > > +  MBA defines a range of MSRs to support specifying a delay value 
> > > (Thrtl) per
> > > +  COS, with details below.
> > > +
> > > +  ```
> > > +   +----------------------------+----------------+
> > > +   | MSR (per socket)           |    Address     |
> > > +   +----------------------------+----------------+
> > > +   | IA32_L2_QOS_Ext_BW_Thrtl_0 |     0xD50      |
> > > +   +----------------------------+----------------+
> > > +   | ...                        |  ...           |
> > > +   +----------------------------+----------------+
> > > +   | IA32_L2_QOS_Ext_BW_Thrtl_n | 0xD50+n (n<64) |
> > > +   +----------------------------+----------------+
> > > +  ```
> > 
> > Are you sure you want to hardcode this n<64? Isn't there a chance this
> > is going to be bumped in newer hardware?
> > 
> This is just a HW limitation declared in SDM. In fact, there is no such hard
> code limitation. Hypervisor side checks the 'cos_max' got through CPUID.

Then I would remove the n<64, or else this will get out-of-sync
without anyone noticing.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.