All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Amit Shah" <amit.shah@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>,
	QEMU <qemu-devel@nongnu.org>,
	"Peter Maydell" <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [PATCH] exec: silence hugetlbfs warning under qtest
Date: Tue, 24 Nov 2015 14:30:10 +0000	[thread overview]
Message-ID: <20151124143010.GL9981@redhat.com> (raw)
In-Reply-To: <20151124162004-mutt-send-email-mst@redhat.com>

On Tue, Nov 24, 2015 at 04:25:40PM +0200, Michael S. Tsirkin wrote:
> 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 <pbonzini@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.

If you are launching QEMU directly that I think it reasonable to expect
people know the difference between giving a guest a hugetlbfs path
vs a regular tmpfs path, and can specifically choose with they prefer.

If launching via libvirt, the error scenario you're concerned about is
impossible, as libvirt will be choosing the hugetlbfs path to match
the requested huge page size from teh guest XML.

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 :|

  reply	other threads:[~2015-11-24 14:30 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-16 17:23 [Qemu-devel] [PATCH 1/3] tests: define qtest-obj-y before using it marcandre.lureau
2015-11-16 17:23 ` [Qemu-devel] [PATCH 2/3] tests: re-enable vhost-user-test marcandre.lureau
2015-11-16 17:23 ` [Qemu-devel] [PATCH 3/3] exec: silence hugetlbfs warning under qtest marcandre.lureau
2015-11-16 21:50   ` Michael S. Tsirkin
2015-11-17 21:32   ` Marc-André Lureau
2015-11-18  8:32     ` Markus Armbruster
2015-11-18  9:02   ` [Qemu-devel] [PATCH] " marcandre.lureau
2015-11-18 20:49     ` Michael S. Tsirkin
2015-11-23 17:40       ` Paolo Bonzini
2015-11-23 17:46         ` Daniel P. Berrange
2015-11-23 17:49           ` Daniel P. Berrange
2015-11-23 18:01         ` Marc-André Lureau
2015-11-23 18:10           ` Daniel P. Berrange
2015-11-24 14:10             ` Michael S. Tsirkin
2015-11-24 14:19               ` Daniel P. Berrange
2015-11-24 14:25                 ` Michael S. Tsirkin
2015-11-24 14:30                   ` Daniel P. Berrange [this message]
2015-11-24 14:30                   ` Paolo Bonzini
2015-11-24 15:29                     ` Michael S. Tsirkin
2015-11-24 15:09                 ` Markus Armbruster
2015-11-24 14:12           ` Michael S. Tsirkin
  -- strict thread matches above, loose matches on Subject: below --
2015-10-27 16:29 marcandre.lureau
2015-10-27 18:37 ` Michael S. Tsirkin
2015-10-29  9:10 ` Michael S. Tsirkin
2015-11-08 17:02 ` Michael S. Tsirkin
2015-11-09  7:50   ` Markus Armbruster
2015-11-12 11:54 ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151124143010.GL9981@redhat.com \
    --to=berrange@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.