From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v2 0/7] KVM: MMU: fast zap all shadow pages
Date: Fri, 22 Mar 2013 19:39:24 +0800 [thread overview]
Message-ID: <514C42EC.6000303@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130322112811.GV9382@redhat.com>
On 03/22/2013 07:28 PM, Gleb Natapov wrote:
> On Fri, Mar 22, 2013 at 07:10:44PM +0800, Xiao Guangrong wrote:
>> On 03/22/2013 06:54 PM, Marcelo Tosatti wrote:
>>
>>>>
>>>>>
>>>>> And then have codepaths that nuke shadow pages break from the spinlock,
>>>>
>>>> I think this is not needed any more. We can let mmu_notify use the generation
>>>> number to invalid all shadow pages, then we only need to free them after
>>>> all vcpus down and mmu_notify unregistered - at this point, no lock contention,
>>>> we can directly free them.
>>>>
>>>>> such as kvm_mmu_slot_remove_write_access does now (spin_needbreak).
>>>>
>>>> BTW, to my honest, i do not think spin_needbreak is a good way - it does
>>>> not fix the hot-lock contention and it just occupies more cpu time to avoid
>>>> possible soft lock-ups.
>>>>
>>>> Especially, zap-all-shadow-pages can let other vcpus fault and vcpus contest
>>>> mmu-lock, then zap-all-shadow-pages release mmu-lock and wait, other vcpus
>>>> create page tables again. zap-all-shadow-page need long time to be finished,
>>>> the worst case is, it can not completed forever on intensive vcpu and memory
>>>> usage.
>>>
>>> Yes, but the suggestion is to use spin_needbreak on the VM shutdown
>>> cases, where there is no detailed concern about performance. Such as
>>> mmu_notifier_release, kvm_destroy_vm, etc. In those cases what matters
>>> most is that host remains unaffected (and that it finishes in a
>>> reasonable time).
>>
>> Okay. I agree with you, will give a try.
>>
>>>
>>>> I still think the right way to fix this kind of thing is optimization for
>>>> mmu-lock.
>>>
>>> And then for the cases where performance matters just increase a
>>> VM global generetion number, zap the roots and then on kvm_mmu_get_page:
>>>
>>> kvm_mmu_get_page() {
>>> sp = lookup_hash(gfn)
>>> if (sp->role = role) {
>>> if (sp->mmu_gen_number != kvm->arch.mmu_gen_number) {
>>> kvm_mmu_commit_zap_page(sp); (no need for TLB flushes as its unreachable)
>>> kvm_mmu_init_page(sp);
>>> proceed as if the page was just allocated
>>> }
>>> }
>>> }
>>>
>>> It makes the kvm_mmu_zap_all path even faster than you have now.
>>> I suppose this was your idea correct with the generation number correct?
>>
>> Wow, great minds think alike, this is exactly what i am doing. ;)
>>
> Not that I disagree with above code, but why not make mmu_gen_number to be
> part of a role and remove old pages in kvm_mmu_free_some_pages() whenever
> limit is reached like we looks to be doing with role.invalid pages now.
These pages can be reused after purge its entries and delete it from parents
list, it can reduce the pressure of memory allocator. Also, we can move it to
the head of active_list so that the pages with invalid_gen can be reclaimed first.
next prev parent reply other threads:[~2013-03-22 11:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 8:30 [PATCH v2 0/7] KVM: MMU: fast zap all shadow pages Xiao Guangrong
2013-03-20 8:30 ` [PATCH v2 1/7] KVM: MMU: introduce mmu_cache->pte_list_descs Xiao Guangrong
2013-03-20 8:30 ` [PATCH v2 2/7] KVM: x86: introduce memslot_set_lpage_disallowed Xiao Guangrong
2013-03-20 8:30 ` [PATCH v2 3/7] KVM: x86: introduce kvm_clear_all_gfn_page_info Xiao Guangrong
2013-03-20 8:30 ` [PATCH v2 4/7] KVM: MMU: delete shadow page from hash list in kvm_mmu_prepare_zap_page Xiao Guangrong
2013-03-21 13:14 ` Gleb Natapov
2013-03-22 2:16 ` Xiao Guangrong
2013-03-20 8:30 ` [PATCH v2 5/7] KVM: MMU: split kvm_mmu_prepare_zap_page Xiao Guangrong
2013-03-20 8:30 ` [PATCH v2 6/7] KVM: MMU: fast zap all shadow pages Xiao Guangrong
2013-03-20 8:30 ` [PATCH v2 7/7] KVM: MMU: drop unnecessary kvm_reload_remote_mmus after kvm_mmu_zap_all Xiao Guangrong
2013-03-21 22:21 ` [PATCH v2 0/7] KVM: MMU: fast zap all shadow pages Marcelo Tosatti
2013-03-22 2:11 ` Xiao Guangrong
2013-03-22 10:01 ` Xiao Guangrong
2013-03-22 10:54 ` Marcelo Tosatti
2013-03-22 11:10 ` Xiao Guangrong
2013-03-22 11:28 ` Gleb Natapov
2013-03-22 11:39 ` Xiao Guangrong [this message]
2013-03-22 11:47 ` Gleb Natapov
2013-03-22 12:03 ` Xiao Guangrong
2013-03-22 12:12 ` Gleb Natapov
2013-03-22 12:37 ` Xiao Guangrong
2013-03-22 19:15 ` Gleb Natapov
2013-04-17 20:39 ` Marcelo Tosatti
2013-04-18 9:42 ` Gleb Natapov
2013-04-18 14:01 ` Marcelo Tosatti
2013-04-18 16:36 ` Gleb Natapov
2013-04-18 17:34 ` Marcelo Tosatti
-- strict thread matches above, loose matches on Subject: below --
2013-03-20 8:29 Xiao Guangrong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=514C42EC.6000303@linux.vnet.ibm.com \
--to=xiaoguangrong@linux.vnet.ibm.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).