[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migratin
From: |
Peter Xu |
Subject: |
Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating |
Date: |
Mon, 24 Feb 2020 12:45:15 -0500 |
On Mon, Feb 24, 2020 at 10:09:19AM +0100, David Hildenbrand wrote:
> On 21.02.20 19:04, Peter Xu wrote:
> > On Fri, Feb 21, 2020 at 05:41:51PM +0100, David Hildenbrand wrote:
> >> I was now able to actually test resizing while migrating. I am using the
> >> prototype of virtio-mem to test (which also makes use of resizable
> >> allocations). Things I was able to reproduce:
> >
> > The test cases cover quite a lot. Thanks for doing that.
> >
> >> - Resize while still running on the migration source. Migration is canceled
> >> -- Test case for "migraton/ram: Handle RAM block resizes during precopy"
> >
> >> - Resize (grow+shrink) on the migration target during postcopy migration
> >> (when syncing RAM blocks), while not yet running on the target
> >> -- Test case for "migration/ram: Discard new RAM when growing RAM blocks
> >> and the VM is stopped", and overall RAM size synchronization. Seems to
> >> work just fine.
> >
> > This won't be able to trigger without virtio-mem, right?
>
> AFAIK all cases can also be triggered without virtio-mem (not just that
> easily :) ). This case would be "RAM block is bigger on source than on
> destination.".
>
> >
> > And I'm also curious on how to test this even with virtio-mem. Is
> > that a QMP command to extend/shrink virtio-mem?
>
> Currently, there is a single qom property that can be modifed via
> QMP/HMP - "requested-size". With resizable resizable memory backends,
> increasing the requested size will also implicitly grow the RAM block.
> Shrinking the requested size will currently result in shrinking the RAM
> block on the next reboot.
>
> So, to trigger growing of a RAM block (assuming requested-size was
> smaller before, e.g., 1000M)
>
> echo "qom-set vm1 requested-size 6000M" | sudo nc -U $MON
>
> To trigger shrinking (assuming requested-size was bigger before)
>
> echo "qom-set vm1 requested-size 100M" | sudo nc -U $MON
> echo 'system_reset' | sudo nc -U $MON
>
>
> Placing these at the right spots during a migration allows to test this
> very reliably.
I see, thanks for the context. The question was majorly about when
you say "during postcopy migration (when syncing RAM blocks), while
not yet running on the target" - it's not easy to do so imho, because:
- it's a very short transition period between precopy and postcopy,
so I was curious about how you made sure that the grow/shrink
happened exactly during that period
- during the period, IIUC it was still in the main thread, which
means logically QEMU should not be able to respond to any QMP/HMP
command at all... So even if you send a command, I think it'll
only be executed later after the transition completes
- this I'm not sure, but ... even for virtio-mem, the resizing can
only happen after guest ack it, right? During the precopy to
postcopy transition period, the VM is stopped, AFAICT, so
logically we can't trigger resizing during the transition
So it's really a question/matter of whether we still even need to
consider that transition period for resizing event for postcopy.
Maybe we don't even need to.
Thanks,
--
Peter Xu
- [PATCH v2 06/13] exec: Relax range check in ram_block_discard_range(), (continued)
- [PATCH v2 06/13] exec: Relax range check in ram_block_discard_range(), David Hildenbrand, 2020/02/21
- [PATCH v2 08/13] migration/ram: Simplify host page handling in ram_load_postcopy(), David Hildenbrand, 2020/02/21
- [PATCH v2 07/13] migration/ram: Discard RAM when growing RAM blocks after ram_postcopy_incoming_init(), David Hildenbrand, 2020/02/21
- [PATCH v2 09/13] migration/ram: Consolidate variable reset after placement in ram_load_postcopy(), David Hildenbrand, 2020/02/21
- [PATCH v2 10/13] migration/ram: Handle RAM block resizes during postcopy, David Hildenbrand, 2020/02/21
- [PATCH v2 11/13] migration/multifd: Print used_length of memory block, David Hildenbrand, 2020/02/21
- [PATCH v2 12/13] migration/ram: Use offset_in_ramblock() in range checks, David Hildenbrand, 2020/02/21
- [PATCH v2 13/13] migration/ram: Tolerate partially changed mappings in postcopy code, David Hildenbrand, 2020/02/21
- Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating, Peter Xu, 2020/02/21
- Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating, David Hildenbrand, 2020/02/24
- Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating,
Peter Xu <=
- Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating, David Hildenbrand, 2020/02/24
- Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating, David Hildenbrand, 2020/02/24
- Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating, Peter Xu, 2020/02/24
- Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating, David Hildenbrand, 2020/02/24
- Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating, Peter Xu, 2020/02/24
- Re: [PATCH v2 00/13] migrate/ram: Fix resizing RAM blocks while migrating, David Hildenbrand, 2020/02/24