nvdimm.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Pankaj Gupta <pagupta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: kwolf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	xiaoguangrong eric
	ross zwisler
Subject: Re: [Qemu-devel] [RFC] qemu: Add virtio pmem device
Date: Thu, 5 Apr 2018 14:19:25 +0200	[thread overview]
Message-ID: <782ac7e2-b8d9-139d-6182-cb4e2d082458@redhat.com> (raw)
In-Reply-To: <416823501.16310251.1522930166070.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

>> So right now you're just using some memdev for testing.
> yes.
>> I assume that the memory region we will provide to the guest will be a
>> simple memory mapped raw file. Dirty tracking (using the kvm slot) will
>> be used to detect which blocks actually changed and have to be flushed
>> to disk.
> Not really, we will perform fsync on raw file. As this file is created
> on regular storage and not nvdimm, so host page cache radix tree would have 
> the dirty pages information which will be used for fsync.

Ah right. That makes things a lot easier!

>> Will this raw file already have the "disk information header" (no idea
>> how that stuff is called) encoded? Are there any plans/possible ways to
>> a) automatically create the headers? (if that's even possible)
> Its raw. Right now we are just supporting raw format.  
> As this is direct mapping of memory into guest address space, I don't
> think we can have an abstraction of headers for block specific features.
> Or may be we can get opinion of others(Qemu block people) it is at all possible?
>> b) support anything but raw files?
>> Please note that under x86, a KVM memory slot still has a (in my
>> opinion) fairly big overhead depending on the size of the slot (rmap,
>> page_track). We might have to optimize that.
> I have not tried/observed this. Right now I just used single memory slot and cold add
> few MB's of memory in Qemu. Can you please provide more details on this?

You can have a look at kvm_arch_create_memslot() in arch/x86/kvm/x86.c.

"npages" is used to allocate certain arrays (rmap for shadow page
tables). Also kvm_page_track_create_memslot() allocates data for page_track.

Having a big disk involves a lot of memory overhead due to the big kvm
memory slot. This is already the case for NVDIMMs as of now.

Other architectures (e.g. s390x) don't have this "problem". They don't
allocate any such data depending on the size of a memory slot.

This is certainly something to work on in the future.



David / dhildenb

  parent reply	other threads:[~2018-04-05 12:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05 10:48 [RFC 0/2] kvm "fake DAX" device flushing Pankaj Gupta
     [not found] ` <20180405104834.10457-1-pagupta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-05 10:48   ` [RFC 1/2] kvm: add virtio pmem driver Pankaj Gupta
2018-04-05 10:48   ` [RFC 2/2] pmem: device flush over VIRTIO Pankaj Gupta
2018-04-05 10:48   ` [RFC] qemu: Add virtio pmem device Pankaj Gupta
     [not found]     ` <20180405104834.10457-4-pagupta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-05 11:26       ` David Hildenbrand
     [not found]         ` <ad08ca09-71ee-08d5-3479-8b3d06380a03-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-05 12:09           ` [Qemu-devel] " Pankaj Gupta
     [not found]             ` <416823501.16310251.1522930166070.JavaMail.zimbra-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-04-05 12:19               ` David Hildenbrand [this message]
2018-04-09  3:26             ` Stefan Hajnoczi
     [not found]               ` <20180409032601.GA1648-lxVrvc10SDRcolVlb+j0YCZi+YwRKgec@public.gmane.org>
2018-04-09  6:42                 ` David Hildenbrand

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=782ac7e2-b8d9-139d-6182-cb4e2d082458@redhat.com \
    --to=david-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=imammedo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=jack-AlSwsSmVLrQ@public.gmane.org \
    --cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=kwolf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org \
    --cc=marcel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=nilal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=niteshnarayanlal-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org \
    --cc=pagupta-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org \
    --cc=riel-ebMLmSuQjDVBDgjK7y7TUQ@public.gmane.org \
    --cc=ross.zwisler-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=stefanha-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=xiaoguangrong.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \


* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).