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