Re: [Xen-devel] [PATCH v6 01/24] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document

[Yi Sun <yi.y.sun@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel