From: David Hildenbrand <david@redhat.com>
To: Peter Xu <peterx@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Juan Quintela <quintela@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Pankaj Gupta <pankaj.gupta@cloud.ionos.com>,
qemu-devel@nongnu.org,
Andrey Gruzdev <andrey.gruzdev@virtuozzo.com>,
Alex Williamson <alex.williamson@redhat.com>,
teawater <teawaterz@linux.alibaba.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Marek Kedzierski <mkedzier@redhat.com>,
Wei Yang <richard.weiyang@linux.alibaba.com>
Subject: Re: [PATCH v2 0/6] migration/ram: Optimize for virtio-mem via RamDiscardManager
Date: Thu, 29 Jul 2021 21:39:24 +0200 [thread overview]
Message-ID: <cebb804b-4b85-8619-0fd0-7aad5a261384@redhat.com> (raw)
In-Reply-To: <YQMCUHWuviDcIc+I@t490s>
>> In the meantime I adjusted the code but it does the clearing under the
>> iothread lock, which should not be what we want ... I'll have a look.
>
> Thanks; if it takes more changes than expected we can still start from simple,
> IMHO, by taking bql and timely yield it.
>
> At the meantime, I found two things in ram_init_bitmaps() that I'm not sure we
> need them of not:
>
> 1. Do we need WITH_RCU_READ_LOCK_GUARD() if with both bql and ramlist lock?
> (small question)
Good question, I'm not sure if we need it.
>
> 2. Do we need migration_bitmap_sync_precopy() even if dirty bmap is all 1's?
> (bigger question)
IIRC, the bitmap sync will fetch the proper dirty bitmap from KVM and
set the proper bits in the clear_bitmap. So once we call
migration_clear_memory_region_dirty_bitmap_range() etc. later we will
actually clear dirty bits.
Without that, migration_clear_memory_region_dirty_bitmap_range() is a
nop and we might migrate stuff unnecessarily twice as dirty bits are not
cleared:
I certainly need that, otherwise the
migration_clear_memory_region_dirty_bitmap_range() is a nop and it all
won't work as you proposed.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2021-07-29 19:40 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-21 9:27 [PATCH v2 0/6] migration/ram: Optimize for virtio-mem via RamDiscardManager David Hildenbrand
2021-07-21 9:27 ` [PATCH v2 1/6] memory: Introduce replay_discarded callback for RamDiscardManager David Hildenbrand
2021-07-23 16:34 ` Peter Xu
2021-07-21 9:27 ` [PATCH v2 2/6] virtio-mem: Implement replay_discarded RamDiscardManager callback David Hildenbrand
2021-07-23 16:34 ` Peter Xu
2021-07-21 9:27 ` [PATCH v2 3/6] migration/ram: Handle RAMBlocks with a RamDiscardManager on the migration source David Hildenbrand
2021-07-21 9:27 ` [PATCH v2 4/6] virtio-mem: Drop precopy notifier David Hildenbrand
2021-07-23 16:34 ` Peter Xu
2021-07-21 9:27 ` [PATCH v2 5/6] migration/postcopy: Handle RAMBlocks with a RamDiscardManager on the destination David Hildenbrand
2021-07-23 16:34 ` Peter Xu
2021-07-23 18:36 ` David Hildenbrand
2021-07-23 18:52 ` Peter Xu
2021-07-23 19:01 ` David Hildenbrand
2021-07-23 22:10 ` Peter Xu
2021-07-29 12:14 ` David Hildenbrand
2021-07-29 15:52 ` Peter Xu
2021-07-29 16:15 ` David Hildenbrand
2021-07-29 19:20 ` Peter Xu
2021-07-29 19:22 ` David Hildenbrand
2021-07-21 9:27 ` [PATCH v2 6/6] migration/ram: Handle RAMBlocks with a RamDiscardManager on background snapshots David Hildenbrand
2021-07-23 16:37 ` Peter Xu
2021-07-22 11:29 ` [PATCH v2 0/6] migration/ram: Optimize for virtio-mem via RamDiscardManager Dr. David Alan Gilbert
2021-07-22 11:43 ` David Hildenbrand
2021-07-23 16:12 ` Peter Xu
2021-07-23 18:41 ` David Hildenbrand
2021-07-23 22:19 ` Peter Xu
2021-07-27 9:25 ` David Hildenbrand
2021-07-27 17:10 ` Peter Xu
2021-07-28 17:39 ` David Hildenbrand
2021-07-28 19:42 ` Peter Xu
2021-07-28 19:46 ` David Hildenbrand
2021-07-28 20:19 ` Peter Xu
2021-07-29 8:14 ` David Hildenbrand
2021-07-29 16:12 ` Peter Xu
2021-07-29 16:19 ` David Hildenbrand
2021-07-29 19:32 ` Peter Xu
2021-07-29 19:39 ` David Hildenbrand [this message]
2021-07-29 20:00 ` Peter Xu
2021-07-29 20:06 ` David Hildenbrand
2021-07-29 20:28 ` Peter Xu
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=cebb804b-4b85-8619-0fd0-7aad5a261384@redhat.com \
--to=david@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=andrey.gruzdev@virtuozzo.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mkedzier@redhat.com \
--cc=mst@redhat.com \
--cc=pankaj.gupta@cloud.ionos.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.weiyang@linux.alibaba.com \
--cc=teawaterz@linux.alibaba.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.