[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [resend v2 0/7] Support cache tune in libvirt



On Tue, Feb 07, 2017 at 10:17:37AM +0000, Daniel P. Berrange wrote:
> On Tue, Feb 07, 2017 at 02:43:13PM +0800, Eli Qiao wrote:
> > > 3) CDP / non-CDP convertion.
> > >  
> > > In case the size determination has been performed with non-CDP,
> > > to emulate such allocation on a CDP host,
> > > it would be good to allow both code and data allocations to share
> > > the CBM space:  
> > >  
> > IOM, I don’t think it’s good to have this.
> > in libvirt capabilities xml, the application will get to know if the host support cdp or not.
> 
> Yep, as long as the capabilities XML provide info about the different
> cache banks, IMHO it is better to have the application be explicit
> about what they want for CDP & non-CDP scenarios.  Let the higher
> level mgmt apps above libvirt apply specific policies if they desire

There is no policy being applied here. What i mean is the following:

1) User determines that the type of the CAT allocation necessary
for his application is one which shares cache and data, that is non-CDP
(either because he didnt have a CDP machine at the time, or because
he had a CDP machine but sharing data and code cache turns out 
to be efficient for the application).
Say that this measured size is M.

2) A host with CDP enabled resctrl is used for this VM. How to create
a CAT allocation with shared code and data? Have to write to the
schemata file of the VM the following:


L3data:1=0x00ff;...
L3code:1=0x00ff;...

(that is, the data and code CBM masks use the same bits).

3) How is the user going to achieve that with this patchset today?
AFAIK, he can't. What he can do is the following:

  <cachetune id='1' host_id='0' type='l3code' size='M' unit='KiB'/>
  <cachetune id='2' host_id='0' type='l3data' size='M' unit='KiB'/>

But this will allocate the following schemata file:

	L3data:1=0xff00;...
	L3code:1=0x00ff;...

Which is not what is wanted.

Therefore the suggestion to _share the cbm bit space_ in case
a similar "cachetune id" is used.

(maybe have a different syntax, i don't care, as long as the user
can create code / data CAT allocations that share the CBM space).

Does that make sense now?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]