[libvirt] [RFC PATCH 0/2] Introduce RDT memory bandwidth allocation support

Pavel Hrdina phrdina at redhat.com
Sat Jun 9 12:28:37 UTC 2018


On Sat, Jun 09, 2018 at 03:13:56PM +0800, bing.niu wrote:
> 
> 
> On 2018年06月08日 21:00, Pavel Hrdina wrote:
> > On Wed, Jun 06, 2018 at 03:46:37PM +0800, bing.niu wrote:
> > > Hi Pavel,
> > > 
> > > On 2018年06月06日 13:56, bing.niu wrote:
> > > 
> > > > > 
> > > > > Then there is the domain XML, for CAT we use this:
> > > > > 
> > > > > <domain>
> > > > >     ...
> > > > >     <cputune>
> > > > >       ...
> > > > >       <cachetune vcpus='0-3'>
> > > > >         <cache id='0' level='3' type='both' size='3' unit='MiB'/>
> > > > >         <cache id='1' level='3' type='both' size='3' unit='MiB'/>
> > > > >       </cachetune>
> > > > >       ...
> > > > >     <cputune>
> > > > >     ...
> > > > > </domain>
> > > > > 
> > > > > so the possible domain XML could look like this:
> > > > > 
> > > > > <domain>
> > > > >     ...
> > > > >     <cputune>
> > > > >       ...
> > > > >       <memory vcpus='0-3'>
> > > > >         <socket id='0' bandwidth='30'/>
> > > > >         <socket id='1' bandwidth='20'/>
> > > > >       </memory>
> > > > >       ...
> > > > >     <cputune>
> > > > >     ...
> > > > > </domain>
> > > > > 
> > > > > Again, the element names 'memory' and 'socket' can be named differently.
> > > > socket --> node?
> > > > 
> > > > Since the existing virrestrl implementation only care about cache part
> > > > during development, So we may need change some names of structure and
> > > > functions when enable MBA. How do you think
> > > > > 
> > > > > Pavel
> > > > > 
> > > > 
> > > Is that possible to support MBA by extending CAT in domain XML? Since each
> > > <cachetune> will map to one virresctrlalloc structure and create a rdt_group
> > > in resctrl fs. Each rdt_group will have it's own closid. this work perfect
> > > if CAT only available. However, if MBA coming in with CAT enabled also, ike
> > > this.
> > > 
> > > <domain>
> > >      ...
> > >      <cputune>
> > >        ...
> > >        <cachetune vcpus='0-3'>
> > >          <cache id='0' level='3' type='both' size='3' unit='MiB'/>
> > >          <cache id='1' level='3' type='both' size='3' unit='MiB'/>
> > >        </cachetune>
> > >       <memory vcpus='2-3'>
> > >         <socket id='0' bandwidth='30'/>
> > >         <socket id='1' bandwidth='20'/>
> > >       </memory>
> > >        ...
> > >      <cputune>
> > >      ...
> > > </domain>
> > > 
> > > we have to make sure those two allocating will not have vcpu overlapped.
> > > like this,
> > > 
> > > if (virBitmapOverlaps(def->cachetunes[i]->vcpus, vcpus)
> > > || virBitmapOverlaps(def->memroy->vcpus, vcpus)) {
> > >               virReportError(VIR_ERR_XML_ERROR, "%s",
> > >                              _("Overlapping vcpus in cachetunes"));
> > >               goto cleanup;
> > > that looks like introducing some dependency between CAT and MBA.
> > > Is that possible we rename cachetune so that handle CAT MBA together one
> > > section?
> > 
> > I would like to avoid mixing cache tune and memory bandwidth under
> > 'cachetune' element.  But this is a good point, we need to make sure
> > that the 'vcpus' is not overlapping.
> > 
> > Renaming existing XML element is not possible, it needs to be backward
> > compatible.
> > 
> > Pavel
> thanks for clarification ;). we will do a cross check about cachetune and
> memory to make sure no vcpus overlapping. I just feel this may confuse
> people. Since we must tell them vcpus cannot overlapping for cachetune and
> memory, but vcpus can be equal. this should be the most common case---
> create one rdt group for one vm.

Yes, I don't like that confusion as well.  We will see how the code will
look like and how it will behave whether it makes sense or not.  If
needed we can change it.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180609/6bc076c0/attachment-0001.sig>


More information about the libvir-list mailing list