Re: [PATCH v2 3/6] Modifies wrapper functions for byte-based phys_ram_dirty bitmap to bit-based phys_ram_dirty bitmap.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/12/2010 01:58 PM, Yoshiaki Tamura wrote:
Is it necessary to update migration and vga bitmaps?

We can simply update the master bitmap, and update the migration and vga
bitmaps only when they need it. That can be done in a different patch.


Let me explain the role of the master bitmap here.

In the previous discussion, the master bitmap represented at least one dirty type is actually dirty. While implementing this approach, I though there is one downside that upon resetting the bitmap, it needs to check all dirty types whether they are already cleared to unset the master bitmap, and this might hurt the performance in general.

The way I see it, the master bitmap is a buffer between the guest and all the other client bitmaps (migration and vga). So, a bit can be set in vga and cleared in master. Let's look at the following scenario:

1. guest touches address 0xa0000 (page 0xa0)
2. qemu updates master bitmap bit 0xa0
3. vga timer fires
4. vga syncs the dirty bitmap for addresses 0xa0000-0xc0000
4.1 vga_bitmap[0xa0-0xc0] |= master_bitmap[0xa0-0xc0]
4.2 migration_bitmap[0xa0-0xc0] |= master_bitmap[0xa0-0xc0]
4.3 master_bitmap[0xa0-0xc0] = 0
5. vga draws based on vga_bitmap

the nice thing is that step 4.2 can be omitted if migration is not active.

so, client bitmaps are always updated when the client requests them, master bitmap is only a buffer.


In this patch, master bitmap represents all types are dirty, similar to existing 0xff. With this approach, resetting the master bitmap can be done without checking the other types. set_dirty_flags is actually taking the burden in this case though. Anyway, IIUC somebody would be unhappy depending on the role of the master bitmap.

Yes, the problem is that set_dirty_flags is the common case and also uses random access, we'd want to make it touch only a single bit. client access is rare, and also sequential, and therefore efficient.


Note that we should only allocate the migration and vga bitmaps when
migration or vga is active.

Right.  May I do it in a different patch?

Sure, more patches is usually better.

I think this is about optimization. In this patch, I focused on not breaking the existing function.

Yes, that's the best approach. But we do need to see how all the incremental steps end up.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux