Re: [PATCH 0/4] KVM: Dirty logging optimization using rmap

[Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>]

(2011/11/29 19:09), Xiao Guangrong wrote:
> Sorry, CC list is lost. :(
>
> On 11/29/2011 06:01 PM, Xiao Guangrong wrote:
>
>> Avi Kivity<avi<at>  redhat.com>  writes:
>>
>>>
>>> On 11/16/2011 06:28 AM, Takuya Yoshikawa wrote:
>>>> (2011/11/14 21:39), Avi Kivity wrote:
>>>>> There was a patchset from Peter Zijlstra that converted mmu notifiers to
>>>>> be preemptible, with that, we can convert the mmu spinlock to a mutex,
>>>>> I'll see what happened to it.
>>>>
>>>> Interesting!
>>>>
>>>>> There is a third method of doing write protection, and that is by
>>>>> write-protecting at the higher levels of the paging hierarchy.  The
>>>>> advantage there is that write protection is O(1) no matter how large the
>>>>> guest is, or the number of dirty pages.
>>>>>
>>>>> To write protect all guest memory, we just write protect the 512 PTEs at
>>>>> the very top, and leave the rest alone.  When the guest writes to a
>>>>> page, we allow writes for the top-level PTE that faulted, and
>>>>> write-protect all the PTEs that it points to.
>>>>
>>>> One important point is that the guest, not GET DIRTY LOG caller, will pay
>>>> for the write protection at the timing of faults.
>>>
>>> I don't think there is a significant difference.  The number of write
>>> faults does not change.  The amount of work done per fault does, but not
>>> by much, thanks to the writeable bitmap.
>>>
>>
>> Avi,
>>
>> I think it needs more thinking if only less page need be write protected.
>>
>> For example, framebuffer-based device used by Xwindow, only ~64M pages needs
>> to be write protected, but in your way, guest will get write page fault on all
>> memory? Hmm?
>>
>> It has some tricks but i missed?

Do you mean write protecting slot by slot is difficult in the case of O(1)?

	Takuya