[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |