[libvirt] [PATCH RFC 1/2] Resctrl: Add new xml element to support cache tune

[Eli Qiao]

hi Martin  

It’s really nice of you to help reviewing the mass code. Thanks.

I don’t find a better way to split patch.  


On Wednesday, 21 June 2017 at 9:53 PM, Martin Kletzander wrote:

> On Mon, Jun 12, 2017 at 05:48:40PM +0800, Eli Qiao wrote:
> > This patch adds new xml element to support cache tune as:
> >  
> > <cputune>
> > ...
> > <cachetune id='0' cache_id='0' level='3' type='both' size='2816' unit='KiB'
> > vcpus='1,2'/>
> >  
>  
>  
> The cache_id automatically implies level and type. Either have one or
> the other. I know we talked about this already (maybe multiple times),
> but without any clear outcome. For me the sensible thing is to have
> level and type as that doesn't need to be changed when moving between
> hosts, and if it cannot be migrated, then it's properly checked.
>  
Think about this case, if the VM has numa setting, the VM has multiple vcpu
running across sockets, if we don’t specify cache_id (cache id stand for
on which Socket/Cache), how can we know on which Socket we allocation for the VM?

I can image there’s 2 cases:

1. if we don’t specify vcpus, and our host have 2 or more Socket, we have this xml define

 <cachetune id='0' level='3' type='both' size='2816' unit=‘KiB’>

We allocate 2816 KiB cache on all of the Socket/Cache.

2. if we specify vcpus
 <cachetune id='0' level='3' type='both' size='2816' unit=‘KiB’, vcpus=‘1,2'>

 <cachetune id=‘1' level='3' type='both' size=‘5632' unit=‘KiB’, vcpus=‘3,4’>

We need to make sure we vcpu 1, 2 are mapped to Socket/Cache 0 and 3,4 on Socket/Cache 1.
So that vcpus running on Socket/Cache 0 has 2816 KiB cache allocated and vcpus running on
Socket/Cache 1 has 5632 KiB cache allocated.

Does it make sense?
  
…


> >  
> > virDomainCputune cputune;
> >  
> > + virDomainCachetune cachetune;
> > +
> >  
>  
>  
> It is part of cputune in the XML, why not here?

Oh yes, I will rethink how to simple the domain cache tune.  
>  
> > virDomainNumaPtr numa;
> > virDomainResourceDefPtr resource;
> > virDomainIdMapDef idmap;
> > --
> > 1.9.1
> >  
> > --
> > libvir-list mailing list
> > libvir-list at redhat.com (mailto:libvir-list at redhat.com)
> > https://www.redhat.com/mailman/listinfo/libvir-list
> >  
>  
>  
> --
> libvir-list mailing list
> libvir-list at redhat.com (mailto:libvir-list at redhat.com)
> https://www.redhat.com/mailman/listinfo/libvir-list
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170622/546f49f7/attachment-0001.htm>