All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: David Hildenbrand <david@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: Fri, 15 May 2020 18:51:05 +0100	[thread overview]
Message-ID: <20200515175105.GL2954@work-vm> (raw)
In-Reply-To: <96a58e88-2629-f2ee-5884-38d11e571548@redhat.com>

* 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.

Dave

> -- 
> Thanks,
> 
> David / dhildenb
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK


WARNING: multiple messages have this Message-ID (diff)
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	kvm@vger.kernel.org, "Michael S . Tsirkin" <mst@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v1 07/17] migration/rdma: Use ram_block_discard_set_broken()
Date: Fri, 15 May 2020 18:51:05 +0100	[thread overview]
Message-ID: <20200515175105.GL2954@work-vm> (raw)
In-Reply-To: <96a58e88-2629-f2ee-5884-38d11e571548@redhat.com>

* 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.

Dave

> -- 
> Thanks,
> 
> David / dhildenb
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



  reply	other threads:[~2020-05-15 17:51 UTC|newest]

Thread overview: 94+ 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 ` David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 01/17] exec: Introduce ram_block_discard_set_(unreliable|required)() David Hildenbrand
2020-05-06  9:49   ` David Hildenbrand
2020-05-15  9:54   ` Dr. David Alan Gilbert
2020-05-15  9:54     ` Dr. David Alan Gilbert
2020-05-15 14:40     ` David Hildenbrand
2020-05-15 14:40       ` David Hildenbrand
2020-05-15 14:54   ` David Hildenbrand
2020-05-15 14:54     ` David Hildenbrand
2020-05-15 16:15     ` Dr. David Alan Gilbert
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-06  9:49   ` David Hildenbrand
2020-05-15 12:01   ` David Hildenbrand
2020-05-15 12:01     ` David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 03/17] accel/kvm: " David Hildenbrand
2020-05-06  9:49   ` David Hildenbrand
2020-05-15 11:57   ` Dr. David Alan Gilbert
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   ` David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 05/17] virtio-balloon: Rip out qemu_balloon_inhibit() David Hildenbrand
2020-05-06  9:49   ` David Hildenbrand
2020-05-15 12:09   ` Dr. David Alan Gilbert
2020-05-15 12:09     ` Dr. David Alan Gilbert
2020-05-15 12:12     ` David Hildenbrand
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-06  9:49   ` David Hildenbrand
2020-05-15 15:51   ` Dr. David Alan Gilbert
2020-05-15 15:51     ` Dr. David Alan Gilbert
2020-05-06  9:49 ` [PATCH v1 07/17] migration/rdma: " David Hildenbrand
2020-05-06  9:49   ` David Hildenbrand
2020-05-15 12:45   ` Dr. David Alan Gilbert
2020-05-15 12:45     ` Dr. David Alan Gilbert
2020-05-15 14:09     ` David Hildenbrand
2020-05-15 14:09       ` David Hildenbrand
2020-05-15 17:51       ` Dr. David Alan Gilbert [this message]
2020-05-15 17:51         ` Dr. David Alan Gilbert
2020-05-15 17:59         ` David Hildenbrand
2020-05-15 17:59           ` David Hildenbrand
2020-05-15 18:36           ` Dr. David Alan Gilbert
2020-05-15 18:36             ` Dr. David Alan Gilbert
2020-05-18 13:52             ` David Hildenbrand
2020-05-18 13:52               ` David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 08/17] migration/colo: " David Hildenbrand
2020-05-06  9:49   ` David Hildenbrand
2020-05-15 13:58   ` Dr. David Alan Gilbert
2020-05-15 13:58     ` Dr. David Alan Gilbert
2020-05-15 14:05     ` David Hildenbrand
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   ` David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 10/17] virtio-mem: Paravirtualized memory hot(un)plug David Hildenbrand
2020-05-06  9:49   ` David Hildenbrand
2020-05-06 16:12   ` Eric Blake
2020-05-06 16:12     ` Eric Blake
2020-05-06 16:14     ` David Hildenbrand
2020-05-06 16:14       ` David Hildenbrand
2020-05-15 15:37   ` Dr. David Alan Gilbert
2020-05-15 15:37     ` Dr. David Alan Gilbert
2020-05-15 16:48     ` David Hildenbrand
2020-05-15 16:48       ` David Hildenbrand
2020-05-18 14:23       ` 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  9:49   ` David Hildenbrand
2020-05-06 18:57   ` Pankaj Gupta
2020-05-06 18:57     ` Pankaj Gupta
2020-05-18 13:34     ` David Hildenbrand
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-06  9:49   ` David Hildenbrand
2020-05-15 15:55   ` Dr. David Alan Gilbert
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  9:49   ` David Hildenbrand
2020-05-06 19:03   ` Pankaj Gupta
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   ` David Hildenbrand
2020-05-06  9:49 ` [PATCH v1 15/17] pc: Support for virtio-mem-pci David Hildenbrand
2020-05-06  9:49   ` David Hildenbrand
2020-05-06 12:19   ` Pankaj Gupta
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-06  9:49   ` David Hildenbrand
2020-05-15 16:46   ` Dr. David Alan Gilbert
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-06  9:49   ` David Hildenbrand
2020-05-15 15:18   ` 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=20200515175105.GL2954@work-vm \
    --to=dgilbert@redhat.com \
    --cc=david@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 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.