lkml.org 
[lkml]   [2013]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 00/12] KVM: MMU: locklessly wirte-protect
From
Date

On Aug 3, 2013, at 1:09 PM, Takuya Yoshikawa <takuya.yoshikawa@gmail.com> wrote:

> On Tue, 30 Jul 2013 21:01:58 +0800
> Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> wrote:
>
>> Background
>> ==========
>> Currently, when mark memslot dirty logged or get dirty page, we need to
>> write-protect large guest memory, it is the heavy work, especially, we need to
>> hold mmu-lock which is also required by vcpu to fix its page table fault and
>> mmu-notifier when host page is being changed. In the extreme cpu / memory used
>> guest, it becomes a scalability issue.
>>
>> This patchset introduces a way to locklessly write-protect guest memory.
>
> Nice improvements!

Thank you!

>
> If I read the patch set correctly, this work contains the following changes:
>
> Cleanups:
> Patch 1 and patch 12.
>
> Lazy large page dropping for dirty logging:
> Patch 2-3.
> Patch 2 is preparatory to patch 3.
>
> This does not look like an RFC if you address Marcelo's comment.
> Any reason to include this in an RFC patch set?

Right, these two patches are not really RFC since you guys have reviewed the
idea.

The reason i put these into this patchset is that they are also the preparing work
for implementing lockless writ-protection since after that we do not need to
remove a spte from the rmap any more. (only need to write-protect a spte.)

>
> Making remote TLBs flushable outside of mmu_lock for dirty logging:
> Patch 6.
>
> This is nice. I'm locally using a similar patch for my work, but yours
> is much cleaner and better. I hope this will get merged soon.

Thanks!

>
> New Pte-list handling:
> Patch 7-9.
>
> Still reading the details.
>
> RCU-based lockless write protection.
> Patch 10-11.
>
> If I understand RCU correctly, the current implementation has a problem:
> read-side critical sections can become too long.
>
> See the following LWN's article:
> "Sleepable RCU"
> https://lwn.net/Articles/202847/
>
> Especially, kvm_mmu_slot_remove_write_access() can take hundreds of
> milliseconds, or even a few seconds for guests using shadow paging.
> Is it possible to break the read-side critical section after protecting
> some pages? -- I guess so.

Yes. we can use the break-tech in the code if it is needed, like this:

if (need_resched()) {
kvm_use_rcu_free_page_end();
kvm_use_rcu_free_page_begin();
}

>
> Anyway, I want to see the following non-RFC quality patches get merged first:
> - Lazy large page dropping for dirty logging:
> - Making remote TLBs flushable outside of mmu_lock for dirty logging
>
> As you are doing in patch 11, the latter can eliminate the TLB flushes before
> cond_resched_lock(). So this alone is an optimization, and since my work is
> based on this TLB flush-less lock breaking, I would appriciate if you make this
> change first in your clean way.

Okay, i will move these patches to the front then the maintainers can merge
them easily.

>
> The remaining patches, pte-list refactoring and lock-less ones, also look
> interesting, but I need to read more to understand them.
>
> Thanks for the nice work!

Thanks for your review and the comments! :)



\
 
 \ /
  Last update: 2013-08-04 16:41    [W:0.326 / U:10.296 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site