[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 10/27] Separate migration bitmap
From: |
Juan Quintela |
Subject: |
Re: [Qemu-devel] [PATCH 10/27] Separate migration bitmap |
Date: |
Thu, 26 Jul 2012 11:22:40 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) |
Avi Kivity <address@hidden> wrote:
> On 07/24/2012 09:36 PM, Juan Quintela wrote:
>> This patch creates a migration bitmap, which is periodically kept in
>> sync with the qemu bitmap. A separate copy of the dirty bitmap for the
>> migration limits the amount of concurrent access to the qemu bitmap
>> from iothread and migration thread (which requires taking the big
>> lock).
>>
>> We use the qemu bitmap type. We have to "undo" the dirty_pages
>> counting optimization on the general dirty bitmap and do the counting
>> optimization with the migration local bitmap.
>
> I had different plans for this (and a stale and possibly smelly patchset
> moving in that direction):
>
> - move the dirty bytemap from a single global instance to
> per-memory-region instances (in the MemoryRegion structure)
> - convert it from a bytemap to either a per-client bitmap (client =
> VGA/CODE/MIGRATION) or a variable bit-length bitfieldmap
> - allocate the bitmaps or strangely named thingie above on demand, so
> ordinarily you have nothing allocated and the framebuffer has a bitmap,
> when you start migration you allocate a bitmap for memory and a
> twobitmap for the framebuffer
> - protect the whole thing using rcu
>
> The patchset is stalled, mostly because it's very difficult to
> disentangle the tcg stuff. I don't think we should introduce a
> dependency here, just something to keep in mind.
I tried something like that myself (before your memory regions work).
And got stuck on the same problem:
- for migration, I always had a ramblock handy
- for vga the same (well, I am not sure for the sparc ones, I think they
were weird on that respect)
- for TCG, there is none around that I can find. I guess it is there
somewhere, but not in any obvious part.
So, to fix TCG, we need a TCG guru, and probably change the access
parters somehow :p
Later, Juan.
- [Qemu-devel] [PATCH 02/27] split MRU ram list, (continued)
- [Qemu-devel] [PATCH 02/27] split MRU ram list, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 06/27] ram: introduce migration_bitmap_set_dirty(), Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 05/27] protect the ramlist with a separate mutex, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 03/27] savevm: Factorize ram globals reset in its own function, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 08/27] ram: Export last_ram_offset(), Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 09/27] ram: introduce migration_bitmap_sync(), Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 12/27] buffered_file: rename opaque to migration_state, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 10/27] Separate migration bitmap, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 07/27] ram: Introduce migration_bitmap_test_and_reset_dirty(), Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 11/27] BufferedFile: append, then flush, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 17/27] buffered_file: unfold migrate_fd_put_buffer, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 16/27] buffered_file: unfold migrate_fd_put_buffer, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 13/27] buffered_file: opaque is MigrationState, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 22/27] migration: make writes blocking, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 21/27] migration: stop all cpus correctly, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 20/27] migration: make qemu_fopen_ops_buffered() return void, Juan Quintela, 2012/07/24
- [Qemu-devel] [PATCH 19/27] buffered_file: Move from using a timer to use a thread, Juan Quintela, 2012/07/24