On Tue, Nov 24, 2015 at 02:19:36PM +0000, Daniel P. Berrange wrote: > On Tue, Nov 24, 2015 at 04:10:54PM +0200, Michael S. Tsirkin wrote: > > On Mon, Nov 23, 2015 at 06:10:08PM +0000, Daniel P. Berrange wrote: > > > On Mon, Nov 23, 2015 at 07:01:33PM +0100, Marc-André Lureau wrote: > > > > On Mon, Nov 23, 2015 at 6:40 PM, Paolo Bonzini <pbonz...@redhat.com> > > > > wrote: > > > > > Before: object-initial, chardev, qtest, object-late (not in the patch) > > > > > > > > > > After: chardev, qtest, object-initial, object-late (not in the patch) > > > > > > > > > > Objects must be initialized before chardev (except rng-egd) since in > > > > > the > > > > > future chardev will need to use objects, in particular secret objects. > > > > > Was the swap intentional? > > > > > > > > Yes, without the swap, qtest was not initialized before memory is > > > > allocated. > > > > > > > > The alternative I could think of is to check the QTEST_QEMU_BINARY > > > > variable: > > > > http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg01527.html > > > > > > Why do we not simply delete the warning message about the path not > > > being on hugetlbfs ? ie, why does QEMU try to force a policy that > > > a memory-file backend has to be on hugetlbfs, as opposed to on > > > a plain tmpfs ? I've previously had user request that we allow > > > use of plain tmpfs, because they want to use vhost-user without > > > also using hugepages, and that could be done with plain tmpfs. > > > > Because THP does not work on any other filesystem, > > so many workloads are much slower. > > That's why it's a warning, not an error. > > AFAICT this warning message is not in a codepath that is specific to > use of THP. This is just generic code for allocating guest memory > backed by a file, which does not have any assumption / prerequisite > that THP is wanted or enabled. So adding warnings that are specifically > related to THP is inappropriate. > > The fact that THP only works with a hugetlbfs path is merely a > documentation item to record against the command line option for > -mem-path.
I'm worried that things go slow and people don't have a way to find out why, and documentation isn't the first place people look for when facing a performance issue. At the moment we call MADV_HUGEPAGE unconditionally and unfortunately there's no way to report it's not having the intended effect. Maybe we want a "don't enable hugepages" flag. That could also have the effect of suppressing the warnings. > > 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 :|
