qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] exec: silence hugetlbfs warning under qtest


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] exec: silence hugetlbfs warning under qtest
Date: Tue, 24 Nov 2015 16:09:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

"Daniel P. Berrange" <address@hidden> writes:

> 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
>> > > <address@hidden> 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.

If a certain workload needs hugepages to perform, it should ask for them
explicitly.  Any means we provide for that purpose should error out when
it can provide them.  Guessing what the user meant and warning him when
we're giving him something else is generally not a good idea.

Whether -object memory-backend-file is a means to explicitly ask for
hugepages is less than clear.  Its file comment says "for hugetlbfs",
but it works just fine with files on other file systems.

Aside: we have *three* copies of gethugepagesize() in the tree: one that
warns in exec.c, one in target-ppc/kvm.c and a third one in
ivshmem-server.c.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]