On 17-02-08 10:56:55, Konrad Rzeszutek Wilk wrote: > On Wed, Feb 08, 2017 at 04:15:53PM +0800, Yi Sun wrote: > > + Every MSR stores a CBM value. A capacity bitmask (CBM) provides a hint > > to the > > + hardware indicating the cache space an application should be limited to > > as > > s/application/VM/ ? > > > + well as providing an indication of overlap and isolation in the > > CAT-capable > > + cache from other applications contending for the cache. > > s/application/VM/ ? > > Perhaps 'domain' as you use that later in the document? > > > + PSR features in future). In some cases, a VM is permitted to have a COS > > I noticed you say 'domain' later on in the document. Would it make > sense to replace s/VM/domain/ to be same in this design? > I think domain should be better.
> > + - Member `ops` > > + > > + `ops` maintains a callback function list of the feature. It will > > be introduced > > + in details later at `4. Feature operation functions structure`. > > I think you can just do: > > [Feature operation functions structure] > > And when you run `pandoc -toc -o intel_psr_cat_cdp.pdf > intel_psr_cat_cdp.pandoc` > > it will provide the right link (which you can follow) to the proper > section. I tried this command but encountered below error. $ pandoc -toc -o intel_psr_cat_cdp.pdf docs/features/intel_psr_cat_cdp.pandoc pandoc: cannot produce pdf output with oc writer > > + root@:~$ xl psr-cat-cbm-set -l2 1 0x7f > > + > > + root@:~$ xl psr-cat-show -l2 1 > > + Socket ID : 0 > > + Default CBM : 0xff > > + ID NAME CBM > > + 1 ubuntu14 0x7f > > + > > +# Areas for improvement > > + > > +N/A > > I would say that using '0x7f' is not very user-friendly. It really > would be good if that changed to something easier to grok. > I agree that '0x7f' is not user-friendly. This needs the user know some HW details. > For example if I am system admin and I look at: > > +----+----+----+----+----+----+----+----+ > | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 | > +----+----+----+----+----+----+----+----+ > COS0 | A | A | A | A | | | | | Isolated Bitmask > +----+----+----+----+----+----+----+----+ > COS1 | | | | | A | A | | | > +----+----+----+----+----+----+----+----+ > COS2 | | | | | | | A | A | > +----+----+----+----+----+----+----+----+ > > I would think that giving an guest 'M7->M4' means it has more > cache than M3->M2 or M1->M0. > > But that is not spelled in details. Or what happens if I do: > +----+----+----+----+----+----+----+----+ > | M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 | > +----+----+----+----+----+----+----+----+ > COS0 | | | | | | A | | | Isolated Bitmask > +----+----+----+----+----+----+----+----+ > COS1 | | | | | | | A | | > +----+----+----+----+----+----+----+----+ > COS2 | | | | | | | | A | > +----+----+----+----+----+----+----+----+ > > Does that have the same effect as the previous one? > I would think not, but perhaps it is the same (we set > three 'pools'). > No, this has different effect. One bit means a quantity of cache capacity, e.g. 1 bit equals 1M. For first case, 0 uses 4M cache, 1 uses 2M, 2 uses 2M. For second case, all three use 1M respectively. Although '0x7F' is not user friendly, it gives the ability to control the granularity of cache allocation. Furthermore, the implementation in Xen is low level interface and we should provide the most flexibility to users. I think the upper layer, e.g. libvirt, may do further wrapper to provide more user friendly interfaces. Thanks, Sun Yi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
