All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zhang Haoyu" <zhanghy@sangfor.com>
To: "Marcus White" <roastedseaweed.k@gmail.com>
Cc: kvm <kvm@vger.kernel.org>
Subject: Re: Some more basic questions..
Date: Fri, 30 May 2014 14:48:26 +0800	[thread overview]
Message-ID: <201405301448239589273@sangfor.com> (raw)
In-Reply-To: CALAJOd2SLjehtqBefsSN-A72u6fVFrnpTd=xEqK4Fz_tOkiEOg@mail.gmail.com

>Thanks Zhang and Venkateshwara, some more follow up questions below:)
>
>1. Does -realtime mlock=on allocate all the memory upfront and keep it
>for the VM, or does it just make sure the memory that is allocated
>within the guest is not swapped out under host memory pressure?
>
“-realtime mlock=on” will mlockall(MCL_CURRENT | MCL_FUTURE) QEMU's ALL memory,
because VM's memory is part of QEMU's, so this option will keep VM's memory unswapped.

>2.  I notice on a 4G guest on an 8G host, guest allocates only about
>1G initially, and the rest later as I start applications. Is there a
>way for me to reserve ALL memory (4G in this case) upfront somehow
>without changes to guest and without allocating it? It will have to be
>something the host OS or some component within the host OS. Isnt there
>something to that effect? It seems odd that there isnt.
>
On linux, user-process's memory is allocating on demand, the physical memory does not allocate until the virtual memory is touched.
Because VM's memory is part of QEMU's, so ...
I guess the VM you said above is linux guest. Windows guest will memset its memory during booting period.

You can use "-realtime mlock=on" to reserve VM's ALL memory upfront.

>
>Thank you in advance.

  reply	other threads:[~2014-05-30  6:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-28 20:59 Some more basic questions Marcus White
2014-05-29  6:04 ` Venkateswara Rao Nandigam
2014-05-29  6:45 ` Zhang Haoyu
2014-05-30  4:06   ` Marcus White
2014-05-30  6:48     ` Zhang Haoyu [this message]
2014-06-02 21:19       ` Marcus White
2014-06-03  3:43         ` Zhang Haoyu
2014-06-03  4:53           ` Marcus White
2014-06-03  6:47             ` Zhang Haoyu
2014-06-03  6:54         ` Venkateswara Rao Nandigam
2014-06-03 11:00         ` Zhang Haoyu
2014-06-03 11:25           ` Venkateswara Rao Nandigam
2014-06-04  1:08             ` Marcus White
2014-06-05  4:42               ` Marcus White
2014-06-12 18:48                 ` Marcus White
2014-06-03 12:51           ` Zhang Haoyu
  -- strict thread matches above, loose matches on Subject: below --
2003-11-10  4:15 Alejandro Sanchez Acosta
2003-11-10 12:17 ` Alex Zarochentsev

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=201405301448239589273@sangfor.com \
    --to=zhanghy@sangfor.com \
    --cc=kvm@vger.kernel.org \
    --cc=roastedseaweed.k@gmail.com \
    /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.