On 04/17/2012 09:26 AM, Xiao Guangrong wrote:
> On 04/16/2012 11:49 PM, Takuya Yoshikawa wrote:
>
>
> > Although O(1) is actually O(1) for GET_DIRTY_LOG thread, it adds some
> > overheads to page fault handling. We may need to hold mmu_lock for properly
> > handling O(1)'s write protection and ~500 write protections will not be so
> > cheap. And there is no answer to the question how to achive slot-wise write
> > protection.
> >
>
>
> Actually no.
>
> We do not increase the overload on page fault for migration. The number of
> page fault of O(1) is the same as write-protect all spte.
That's true with the write protect everything approach we use now. But
it's not true with range-based write protection, where you issue
GET_DIRTY_LOG on a range of pages and only need to re-write-protect them.
(the motivation for that is to decrease the time between GET_DIRTY_LOG
and sending the page; as the time increases, the chances that the page
got re-dirtied go up).
That doesn't mean O(1) is unusable for this, just that it requires more
thought. Especially with direct maps, we can write-enable pages very
quickly.
> And, we can also avoid to hold mmu_lock to write-protect PML4s, we can use
> a generation number, and notify mmu to update its page table when dirty-log
> is enabled.
Generation numbers are also useful for o(1) invalidation.
>
> Anyway, no performance data, no truth. Let me implement it first.
>
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[KVM Development]
[KVM ARM]
[KVM ia64]
[Linux USB Devel]
[Linux Video]
[Linux Audio Users]
[Photo]
[Video Projectors]
[PDAs]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]
[Big List of Linux Books]