All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org,
	john cooper <john.cooper@redhat.com>,
	avi@redhat.com
Subject: Re: [Qemu-devel] [patch uq/master 2/2] Add option to use file backed guest memory
Date: Mon, 1 Mar 2010 20:32:39 -0300	[thread overview]
Message-ID: <20100301233239.GA21535@amt.cnet> (raw)
In-Reply-To: <20100301232508.GA13703@amt.cnet>

On Mon, Mar 01, 2010 at 08:25:08PM -0300, Marcelo Tosatti wrote:
> Hi Paul,
> 
> Thank you for reviewing.
> 
> On Sun, Feb 28, 2010 at 01:28:16AM +0000, Paul Brook wrote:
> > IMHO it would be better to check the mem_path != NULL here, rather that 
> > burying the check in file_ram_alloc.
> > 
> > >+    if (memory < hpagesize) {
> > >+        return NULL;
> > >+    }
> > 
> > Ah, so it's actually "allocate memory in $path, if you feel like it". Good job 
> > we aren't relying on this for correctness.  At minimum I recommend documenting 
> > this heuristic.
> 
> More like "allocate memory in $path, if it its larger than a hugepage."
> 
> Huge pages are an optimization.
> 
> > 
> > >+    if (!new_block->host) {
> > > #if defined(TARGET_S390X) && defined(CONFIG_KVM)
> > >-    /* XXX S390 KVM requires the topmost vma of the RAM to be < 256GB */
> > 
> > By my reading this implies -mempath is probably broken on s390 KVM?
> > 
> > >+DEF("mem-path", HAS_ARG, QEMU_OPTION_mempath,
> > >+    "-mem-path FILE  provide backing storage for guest RAM\n")
> > >+STEXI
> > >+@item -mem-path @var{path}
> > >+Allocate guest RAM from a temporarily created file in @var{path}.
> > >+ETEXI
> > 
> > You should mention that this is only useful when PATH happens to be a linux 
> > hugetlbfs mount.
> 
> It can be used with a file, since its mapped as MAP_PRIVATE.

I meant non hugetlbfs backed file.


WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Paul Brook <paul@codesourcery.com>
Cc: john cooper <john.cooper@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org, avi@redhat.com
Subject: Re: [Qemu-devel] [patch uq/master 2/2] Add option to use file backed guest memory
Date: Mon, 1 Mar 2010 20:32:39 -0300	[thread overview]
Message-ID: <20100301233239.GA21535@amt.cnet> (raw)
In-Reply-To: <20100301232508.GA13703@amt.cnet>

On Mon, Mar 01, 2010 at 08:25:08PM -0300, Marcelo Tosatti wrote:
> Hi Paul,
> 
> Thank you for reviewing.
> 
> On Sun, Feb 28, 2010 at 01:28:16AM +0000, Paul Brook wrote:
> > IMHO it would be better to check the mem_path != NULL here, rather that 
> > burying the check in file_ram_alloc.
> > 
> > >+    if (memory < hpagesize) {
> > >+        return NULL;
> > >+    }
> > 
> > Ah, so it's actually "allocate memory in $path, if you feel like it". Good job 
> > we aren't relying on this for correctness.  At minimum I recommend documenting 
> > this heuristic.
> 
> More like "allocate memory in $path, if it its larger than a hugepage."
> 
> Huge pages are an optimization.
> 
> > 
> > >+    if (!new_block->host) {
> > > #if defined(TARGET_S390X) && defined(CONFIG_KVM)
> > >-    /* XXX S390 KVM requires the topmost vma of the RAM to be < 256GB */
> > 
> > By my reading this implies -mempath is probably broken on s390 KVM?
> > 
> > >+DEF("mem-path", HAS_ARG, QEMU_OPTION_mempath,
> > >+    "-mem-path FILE  provide backing storage for guest RAM\n")
> > >+STEXI
> > >+@item -mem-path @var{path}
> > >+Allocate guest RAM from a temporarily created file in @var{path}.
> > >+ETEXI
> > 
> > You should mention that this is only useful when PATH happens to be a linux 
> > hugetlbfs mount.
> 
> It can be used with a file, since its mapped as MAP_PRIVATE.

I meant non hugetlbfs backed file.

  reply	other threads:[~2010-03-01 23:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-24 21:11 [patch uq/master 0/2] port qemu-kvm's -mem-path and -mem-prealloc to qemu Marcelo Tosatti
2010-02-24 21:11 ` [Qemu-devel] " Marcelo Tosatti
2010-02-24 21:11 ` [patch uq/master 1/2] Allocate memory below 4GB as one chunk Marcelo Tosatti
2010-02-24 21:11   ` [Qemu-devel] " Marcelo Tosatti
2010-02-25 13:33   ` Avi Kivity
2010-02-25 13:33     ` [Qemu-devel] " Avi Kivity
2010-02-24 21:11 ` [patch uq/master 2/2] Add option to use file backed guest memory Marcelo Tosatti
2010-02-24 21:11   ` [Qemu-devel] " Marcelo Tosatti
2010-02-28  1:28   ` Paul Brook
2010-02-28  1:28     ` Paul Brook
2010-03-01 23:25     ` Marcelo Tosatti
2010-03-01 23:25       ` Marcelo Tosatti
2010-03-01 23:32       ` Marcelo Tosatti [this message]
2010-03-01 23:32         ` Marcelo Tosatti
2010-02-25 13:32 ` [patch uq/master 0/2] port qemu-kvm's -mem-path and -mem-prealloc to qemu Avi Kivity
2010-02-25 13:32   ` [Qemu-devel] " Avi Kivity

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=20100301233239.GA21535@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=avi@redhat.com \
    --cc=john.cooper@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=paul@codesourcery.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.