From: Chris Friesen <chris.friesen@windriver.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [dpdk-dev] Will huge page have negative effect on guest vm in qemu enviroment?
Date: Wed, 21 Jun 2017 13:35:29 -0600 [thread overview]
Message-ID: <594ACA81.3010402@windriver.com> (raw)
In-Reply-To: <20170621191601.GB2425@work-vm>
On 06/21/2017 01:16 PM, Dr. David Alan Gilbert wrote:
> * Sam (batmanustc@gmail.com) wrote:
>> Thank you~
>>
>> 1. We have a compare test on qemu-kvm enviroment with huge page and without
>> huge page. Qemu start process is much longer in huge page enviromwnt. And I
>> write an email titled with '[DPDK-memory] how qemu waste such long time
>> under dpdk huge page envriment?'. I could resend it later.
>
>> 2. Then I have another test on qemu-kvm enviroment with huge page and
>> without huge page, which I didn't start ovs-dpdk and vhostuser port in qemu
>> start process. And I found Qemu start process is also much longer in huge
>> page enviroment.
>>
>> So I think huge page enviroment, which grub2.cfg file is specified in
>> ‘[DPDK-memory]
>> how qemu waste such long time under dpdk huge page envriment?’, will really
>> have negative effect on qemu start up process.
>>
>> That's why we don't like to use ovs-dpdk. Althrough ovs-dpdk is faster, but
>> the start up process of qemu is much longer then normal ovs, and the reason
>> is nothing with ovs but huge page. For customers, vm start up time is
>> important then network speed.
>
> How are you setting up hugepages? What values are you putting in the
> various /proc or cmdline options and how are you specifying them on
> QEMU's commandline.
>
> I think one problem is that with hugepages qemu normally allocates them
> all at the start; I think there are cases where that means moving a lot
> of memory about, especially if you lock it to particular NUMA nodes.
For what it's worth, we use something like this:
-object
memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/mnt/huge-2048kB/libvirt/qemu,share=yes,size=2147483648,host-nodes=0,policy=bind
-numa node,nodeid=0,cpus=0-3,memdev=ram-node0
and I haven't noticed it taking particularly long to start up. All our
hugepages are reserved at host startup though.
Chris
next prev parent reply other threads:[~2017-06-21 19:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-21 3:32 Will huge page have negative effect on guest vm in qemu enviroment? Sam
2017-06-21 3:32 ` [Qemu-devel] " Sam
2017-06-21 3:35 ` Sam
2017-06-21 3:35 ` [Qemu-devel] " Sam
2017-06-21 6:15 ` Pavel Shirshov
2017-06-21 6:15 ` [Qemu-devel] [dpdk-dev] " Pavel Shirshov
2017-06-21 7:22 ` Sam
2017-06-21 7:22 ` [Qemu-devel] [dpdk-dev] " Sam
2017-06-21 9:03 ` Gaëtan Rivet
2017-06-21 19:16 ` [Qemu-devel] " Dr. David Alan Gilbert
2017-06-21 19:16 ` [Qemu-devel] [dpdk-dev] " Dr. David Alan Gilbert
2017-06-21 19:35 ` Chris Friesen [this message]
2017-06-22 9:24 ` Alejandro Lucero
2017-06-22 9:24 ` [Qemu-devel] [dpdk-dev] " Alejandro Lucero
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=594ACA81.3010402@windriver.com \
--to=chris.friesen@windriver.com \
--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.