Re: Balloon pressuring page cache

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

 



>> 1. Guest allocates a page and sends it to the host.
>> 2. Shrinker gets active and releases that page again.
>> 3. Some user in the guest allocates and modifies that page. The dirty bit is
>> set in the hypervisor.
> 
> The bit will be set in KVM's bitmap, and will be synced to QEMU's bitmap when the next round starts.
> 
>> 4. The host processes the request and clears the bit in the dirty bitmap.
> 
> This clears the bit from the QEMU bitmap, and this page will not be sent in this round.
> 
>> 5. The guest is stopped and the last set of dirty pages is migrated. The
>> modified page is not being migrated (because not marked dirty).
> 
> When QEMU start the last round, it first syncs the bitmap from KVM, which includes the one set in step 3.
> Then the modified page gets sent.

So, if you run a TCG guest and use it with free page reporting, the race
is possible? So the correctness depends on two dirty bitmaps in the
hypervisor and how they interact. wow this is fragile.

Thanks for the info :)

-- 
Thanks,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux