[libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

[Marcelo Tosatti]

On Wed, Feb 05, 2014 at 09:49:53AM +0000, Daniel P. Berrange wrote:
> On Tue, Feb 04, 2014 at 03:04:11PM -0700, Eric Blake wrote:
> > On 02/04/2014 02:57 PM, Marcelo Tosatti wrote:
> > > 
> > >> So perhaps we do need some "policy" attribute on the <hugepages/>
> > >> element to indicate desired behaviour here.
> > > 
> > > What about the following new element under <hugepages/> ?
> > > 
> > > enforce_hugepage_size=integer 
> > 
> > Which feels a bit redundant (we're already under the <hugepages>
> > element, after all).  Maybe:
> > 
> > <hugepages>
> >   <size strict='yes' unit='G'>1</size>
> > </hugepages>
> > 
> > where strict could be no if we are giving a hint but don't care if the
> > hint cannot be honored (default yes if omitted), and where unit + value
> > allows the user to input the size in a sensible unit (on output, we'd
> > probably want to use unit='k' and spell out 1048576, for similarity with
> > all our other memory interfaces that output in k for back-compat reasons).
> 
> I don't think strict=yes|no is neccessarily the best. Per my previous
> mail in this thread there are at least 3 possible policies that could
> be implemented. 
> 
>  - Require memory size multiple of hugepage size

Awkward. If the memory size is not multiple of hugepage size it should 
still be possible to start the guest (although using smaller page
sizes).

>  - Round memory size upto multiple of huge page size

QEMU decides, today, whether or not to do this.

>  - Fill in with smaller huge pages

Again, QEMU can decide this automatically.

> So I'd say   policy="round|exact|bestfit"  even if QEMU doesn't decide
> to actually implement all 3 possible policies, we at least futureproof
> ourselves by not using a boolean.

The request is the following: certain applications require the
TLB performance characteristics provided by certain page sizes.
For this type of application, the minimum page size is given. Below that
page size, its known that the application cannot perform as expected, so 
guest initialization should instead fail.

Except that case, there is no necessity to specify the options you list
above. 

IMO the options should not be created unless their practical use has
been verified. So going for

<hugepages>
  <size unit='K/G/M'>x</size>
</hugepages>

Which is very precise and can be extended.

Thanks for the suggestions