From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1Ebs-0000vh-9M for qemu-devel@nongnu.org; Tue, 24 Nov 2015 09:30:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1Ebn-0004sW-So for qemu-devel@nongnu.org; Tue, 24 Nov 2015 09:30:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1Ebn-0004sM-Lu for qemu-devel@nongnu.org; Tue, 24 Nov 2015 09:30:15 -0500 Date: Tue, 24 Nov 2015 14:30:10 +0000 From: "Daniel P. Berrange" Message-ID: <20151124143010.GL9981@redhat.com> References: <1447694618-17177-3-git-send-email-marcandre.lureau@redhat.com> <1447837378-25222-1-git-send-email-marcandre.lureau@redhat.com> <20151118224821-mutt-send-email-mst@redhat.com> <56534FAA.4090101@redhat.com> <20151123181008.GU18085@redhat.com> <20151124160921-mutt-send-email-mst@redhat.com> <20151124141936.GJ9981@redhat.com> <20151124162004-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20151124162004-mutt-send-email-mst@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] exec: silence hugetlbfs warning under qtest Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Amit Shah , Paolo Bonzini , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , QEMU , Peter Maydell 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=C3=A9 Lureau = wrote: > > > > > On Mon, Nov 23, 2015 at 6:40 PM, Paolo Bonzini wrote: > > > > > > Before: object-initial, chardev, qtest, object-late (not in t= he patch) > > > > > > > > > > > > After: chardev, qtest, object-initial, object-late (not in th= e patch) > > > > > > > > > > > > Objects must be initialized before chardev (except rng-egd) s= ince in the > > > > > > future chardev will need to use objects, in particular secret= objects. > > > > > > Was the swap intentional? > > > > >=20 > > > > > Yes, without the swap, qtest was not initialized before memory = is allocated. > > > > >=20 > > > > > The alternative I could think of is to check the QTEST_QEMU_BIN= ARY > > > > > variable: http://lists.nongnu.org/archive/html/qemu-devel/2015-= 11/msg01527.html > > > >=20 > > > > Why do we not simply delete the warning message about the path no= t > > > > 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. > > >=20 > > > 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. > >=20 > > 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 specifical= ly > > related to THP is inappropriate. > >=20 > > 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. >=20 > 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 facin= g > 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 --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|