kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org,
	qemu-s390x@nongnu.org, Richard Henderson <rth@twiddle.net>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [PATCH v1 07/17] migration/rdma: Use ram_block_discard_set_broken()
Date: Mon, 18 May 2020 15:52:55 +0200	[thread overview]
Message-ID: <f47032a1-7a44-cfc8-18ce-f0a9b4a010b6@redhat.com> (raw)
In-Reply-To: <20200515183652.GM2954@work-vm>

On 15.05.20 20:36, Dr. David Alan Gilbert wrote:
> * David Hildenbrand (david@redhat.com) wrote:
>> On 15.05.20 19:51, Dr. David Alan Gilbert wrote:
>>> * David Hildenbrand (david@redhat.com) wrote:
>>>> On 15.05.20 14:45, Dr. David Alan Gilbert wrote:
>>>>> * David Hildenbrand (david@redhat.com) wrote:
>>>>>> RDMA will pin all guest memory (as documented in docs/rdma.txt). We want
>>>>>> to mark RAM block discards to be broken - however, to keep it simple
>>>>>> use ram_block_discard_is_required() instead of inhibiting.
>>>>>
>>>>> Should this be dependent on whether rdma->pin_all is set?
>>>>> Even with !pin_all some will be pinned at any given time
>>>>> (when it's registered with the rdma stack).
>>>>
>>>> Do you know how much memory this is? Is such memory only temporarily pinned?
>>>
>>> With pin_all not set, only a subset of memory, I think multiple 1MB
>>> chunks, are pinned at any one time.
>>>
>>>> At least with special-cases of vfio, it's acceptable if some memory is
>>>> temporarily pinned - we assume it's only the working set of the driver,
>>>> which guests will not inflate as long as they don't want to shoot
>>>> themselves in the foot.
>>>>
>>>> This here sounds like the guest does not know the pinned memory is
>>>> special, right?
>>>
>>> Right - for RDMA it's all of memory that's being transferred, and the
>>> guest doesn't see when each part is transferred.
>>
>>
>> Okay, so all memory will eventually be pinned, just not at the same
>> time, correct?
>>
>> I think this implies that any memory that was previously discarded will
>> be backed my new pages, meaning we will consume more memory than intended.
>>
>> If so, always disabling discarding of RAM seems to be the right thing to do.
> 
> Yeh that's probably true, although there's a check for 'buffer_is_zero'
> in the !rdma->pin_all case, if the entire area is zero (or probably if
> unmapped) then it sends a notification rather than registering; see
> qemu_rdma_write_one and search for 'This chunk has not yet been
> registered, so first check to see'

Right, if the whole chunk is zero, it will send a "compressed" zero
chunk to the target. That will result in a memset() in case the
destination is not already zero. So, both the source and the destination
will be at least be read.

But this only works if a complete chunk (1MB) is zero IIUC. If only one
page within a chunk is not zero (e.g., not inflated), the whole chunk
will be pinned. Also, "disabled chunk registration" seems to be another
case.

https://wiki.qemu.org/Features/RDMALiveMigration

"Finally, zero pages are only checked if a page has not yet been
registered using chunk registration (or not checked at all and
unconditionally written if chunk registration is disabled. This is
accomplished using the "Compress" command listed above. If the page
*has* been registered then we check the entire chunk for zero. Only if
the entire chunk is zero, then we send a compress command to zap the
page on the other side."

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2020-05-18 13:53 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06  9:49 [PATCH v1 00/17] virtio-mem: Paravirtualized memory hot(un)plug David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 01/17] exec: Introduce ram_block_discard_set_(unreliable|required)() David Hildenbrand
2020-05-15  9:54   ` Dr. David Alan Gilbert
2020-05-15 14:40     ` David Hildenbrand
2020-05-15 14:54   ` David Hildenbrand
2020-05-15 16:15     ` Dr. David Alan Gilbert
2020-05-06  9:49 ` [PATCH v1 02/17] vfio: Convert to ram_block_discard_set_broken() David Hildenbrand
2020-05-15 12:01   ` David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 03/17] accel/kvm: " David Hildenbrand
2020-05-15 11:57   ` Dr. David Alan Gilbert
2020-05-06  9:49 ` [PATCH v1 04/17] s390x/pv: " David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 05/17] virtio-balloon: Rip out qemu_balloon_inhibit() David Hildenbrand
2020-05-15 12:09   ` Dr. David Alan Gilbert
2020-05-15 12:12     ` David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 06/17] target/i386: sev: Use ram_block_discard_set_broken() David Hildenbrand
2020-05-15 15:51   ` Dr. David Alan Gilbert
2020-05-06  9:49 ` [PATCH v1 07/17] migration/rdma: " David Hildenbrand
2020-05-15 12:45   ` Dr. David Alan Gilbert
2020-05-15 14:09     ` David Hildenbrand
2020-05-15 17:51       ` Dr. David Alan Gilbert
2020-05-15 17:59         ` David Hildenbrand
2020-05-15 18:36           ` Dr. David Alan Gilbert
2020-05-18 13:52             ` David Hildenbrand [this message]
2020-05-06  9:49 ` [PATCH v1 08/17] migration/colo: " David Hildenbrand
2020-05-15 13:58   ` Dr. David Alan Gilbert
2020-05-15 14:05     ` David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 09/17] linux-headers: update to contain virtio-mem David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 10/17] virtio-mem: Paravirtualized memory hot(un)plug David Hildenbrand
2020-05-06 16:12   ` Eric Blake
2020-05-06 16:14     ` David Hildenbrand
2020-05-15 15:37   ` Dr. David Alan Gilbert
2020-05-15 16:48     ` David Hildenbrand
2020-05-18 14:23       ` David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 11/17] virtio-pci: Proxy for virtio-mem David Hildenbrand
2020-05-06 18:57   ` Pankaj Gupta
2020-05-18 13:34     ` David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 12/17] MAINTAINERS: Add myself as virtio-mem maintainer David Hildenbrand
2020-05-15 15:55   ` Dr. David Alan Gilbert
2020-05-06  9:49 ` [PATCH v1 13/17] hmp: Handle virtio-mem when printing memory device info David Hildenbrand
2020-05-06 19:03   ` Pankaj Gupta
2020-05-06  9:49 ` [PATCH v1 14/17] numa: Handle virtio-mem in NUMA stats David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 15/17] pc: Support for virtio-mem-pci David Hildenbrand
2020-05-06 12:19   ` Pankaj Gupta
2020-05-06  9:49 ` [PATCH v1 16/17] virtio-mem: Allow notifiers for size changes David Hildenbrand
2020-05-15 16:46   ` Dr. David Alan Gilbert
2020-05-06  9:49 ` [PATCH v1 17/17] virtio-pci: Send qapi events when the virtio-mem " David Hildenbrand
2020-05-15 15:18   ` 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:
  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=f47032a1-7a44-cfc8-18ce-f0a9b4a010b6@redhat.com \
    --to=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=rth@twiddle.net \
    /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 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).