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

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

 



On Tue, Feb 04, 2014 at 11:54:22AM -0500, Marcelo Tosatti wrote:
> On Tue, Feb 04, 2014 at 04:42:02PM +0000, Daniel P. Berrange wrote:
> > On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote:
> > > 
> > > Add an element named "strict-hugepages" to control whether to 
> > > refuse guest initialization in case hugepage allocation cannot 
> > > be performed.
> > > 
> > > Signed-off-by: Marcelo Tosatti <mtosatti@xxxxxxxxxx>
> > > 
> > > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> > > index ff50214..e79f5e6 100644
> > > --- a/docs/formatdomain.html.in
> > > +++ b/docs/formatdomain.html.in
> > > @@ -632,6 +632,9 @@
> > >        <dt><code>hugepages</code></dt>
> > >        <dd>This tells the hypervisor that the guest should have its memory
> > >          allocated using hugepages instead of the normal native page size.</dd>
> > > +      <dt><code>strict-hugepages</code></dt>
> > > +      <dd>This tells the hypervisor that the guest should refuse to start
> > > +          in case of failure to allocate guest memory with hugepages</dd>
> > 
> > Huh, we already supply the -mem-prealloc command line flag alongside
> > the -mem-path flag which should cause QEMU to exit if it cannot allocate
> > all memory upfront.
> 
>        -mem-path path
>            Allocate guest RAM from a temporarily created file in path.
> 
>        -mem-prealloc
>            Preallocate memory when using -mem-path.
> 
> "should cause QEMU to exit if it cannot allocate all memory upfront" =>
> no it does not. See more below.

I'd say that is a bug - if it is failing to pre-allocate all the
memory when asked todo so, then it should exit with an error IMHO.

> > libvirt to the private implementation detail of QEMU's backing file
> 
> Right. I am going to add a comment to QEMU saying libvirt interprets the
> string (so that changing it breaks libvirt). Other tools already do
> this.

It is just plain bad design to expose internals of QEMU to libvirt in
this way. QEMU is perfectly capable of enforcing this itself and thus
retaining the flexibility to change its impl later, without binding
together libvirt + QEMU in this way.

> > naming. On top of which I don't see why we need this when we're already
> > setting -mem-prealloc to enforce exactly this.
> 
> Because there is no guarantee with -mem-prealloc. For instance, if the
> hugepage path is not actually hugetlbfs backed, QEMU falls back to
> malloc().

Well if you can't fix -mem-prealloc to properly report errors for reasons
of back compat, then it is certainly possible to add a further 'strict=yes|no'
option to the CLI arg request that it verify this. I don't see any reason
why this checking code should be in libvirt rather than QEMU.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]