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" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
