public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Cc: gleb@redhat.com, avi.kivity@gmail.com,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	takuya.yoshikawa@gmail.com
Subject: Re: [PATCH v4 4/6] KVM: MMU: fast invalid all shadow pages
Date: Mon, 6 May 2013 16:50:22 -0300	[thread overview]
Message-ID: <20130506195022.GA5706@amt.cnet> (raw)
In-Reply-To: <518725DF.5090503@linux.vnet.ibm.com>

On Mon, May 06, 2013 at 11:39:11AM +0800, Xiao Guangrong wrote:
> On 05/04/2013 08:52 AM, Marcelo Tosatti wrote:
> > On Sat, May 04, 2013 at 12:51:06AM +0800, Xiao Guangrong wrote:
> >> On 05/03/2013 11:53 PM, Marcelo Tosatti wrote:
> >>> On Fri, May 03, 2013 at 01:52:07PM +0800, Xiao Guangrong wrote:
> >>>> On 05/03/2013 09:05 AM, Marcelo Tosatti wrote:
> >>>>
> >>>>>> +
> >>>>>> +/*
> >>>>>> + * Fast invalid all shadow pages belong to @slot.
> >>>>>> + *
> >>>>>> + * @slot != NULL means the invalidation is caused the memslot specified
> >>>>>> + * by @slot is being deleted, in this case, we should ensure that rmap
> >>>>>> + * and lpage-info of the @slot can not be used after calling the function.
> >>>>>> + *
> >>>>>> + * @slot == NULL means the invalidation due to other reasons, we need
> >>>>>> + * not care rmap and lpage-info since they are still valid after calling
> >>>>>> + * the function.
> >>>>>> + */
> >>>>>> +void kvm_mmu_invalid_memslot_pages(struct kvm *kvm,
> >>>>>> +				   struct kvm_memory_slot *slot)
> >>>>>> +{
> >>>>>> +	spin_lock(&kvm->mmu_lock);
> >>>>>> +	kvm->arch.mmu_valid_gen++;
> >>>>>> +
> >>>>>> +	/*
> >>>>>> +	 * All shadow paes are invalid, reset the large page info,
> >>>>>> +	 * then we can safely desotry the memslot, it is also good
> >>>>>> +	 * for large page used.
> >>>>>> +	 */
> >>>>>> +	kvm_clear_all_lpage_info(kvm);
> >>>>>
> >>>>> Xiao,
> >>>>>
> >>>>> I understood it was agreed that simple mmu_lock lockbreak while
> >>>>> avoiding zapping of newly instantiated pages upon a
> >>>>>
> >>>>> 	if(spin_needbreak)
> >>>>> 		cond_resched_lock()
> >>>>>
> >>>>> cycle was enough as a first step? And then later introduce root zapping
> >>>>> along with measurements.
> >>>>>
> >>>>> https://lkml.org/lkml/2013/4/22/544
> >>>>
> >>>> Yes, it is.
> >>>>
> >>>> See the changelog in 0/0:
> >>>>
> >>>> " we use lock-break technique to zap all sptes linked on the
> >>>> invalid rmap, it is not very effective but good for the first step."
> >>>>
> >>>> Thanks!
> >>>
> >>> Sure, but what is up with zeroing kvm_clear_all_lpage_info(kvm) and
> >>> zapping the root? Only lock-break technique along with generation number 
> >>> was what was agreed.
> >>
> >> Marcelo,
> >>
> >> Please Wait... I am completely confused. :(
> >>
> >> Let's clarify "zeroing kvm_clear_all_lpage_info(kvm) and zapping the root" first.
> >> Are these changes you wanted?
> >>
> >> void kvm_mmu_invalid_memslot_pages(struct kvm *kvm,
> >> 				   struct kvm_memory_slot *slot)
> >> {
> >> 	spin_lock(&kvm->mmu_lock);
> >> 	kvm->arch.mmu_valid_gen++;
> >>
> >> 	/* Zero all root pages.*/
> >> restart:
> >> 	list_for_each_entry_safe(sp, node, &kvm->arch.active_mmu_pages, link) {
> >> 		if (!sp->root_count)
> >> 			continue;
> >>
> >> 		if (kvm_mmu_prepare_zap_page(kvm, sp, &invalid_list))
> >> 			goto restart;
> >> 	}
> >>
> >> 	/*
> >> 	 * All shadow paes are invalid, reset the large page info,
> >> 	 * then we can safely desotry the memslot, it is also good
> >> 	 * for large page used.
> >> 	 */
> >> 	kvm_clear_all_lpage_info(kvm);
> >>
> >> 	kvm_mmu_commit_zap_page(kvm, &invalid_list);
> >> 	spin_unlock(&kvm->mmu_lock);
> >> }
> >>
> >> static void rmap_remove(struct kvm *kvm, u64 *spte)
> >> {
> >> 	struct kvm_mmu_page *sp;
> >> 	gfn_t gfn;
> >> 	unsigned long *rmapp;
> >>
> >> 	sp = page_header(__pa(spte));
> >> +
> >> +       /* Let invalid sp do not access its rmap. */
> >> +	if (!sp_is_valid(sp))
> >> +		return;
> >> +
> >> 	gfn = kvm_mmu_page_get_gfn(sp, spte - sp->spt);
> >> 	rmapp = gfn_to_rmap(kvm, gfn, sp->role.level);
> >> 	pte_list_remove(spte, rmapp);
> >> }
> >>
> >> If yes, there is the reason why we can not do this that i mentioned before:
> >>
> >> after call kvm_mmu_invalid_memslot_pages(), the memslot->rmap will be destroyed.
> >> Later, if host reclaim page, the mmu-notify handlers, ->invalidate_page and
> >> ->invalidate_range_start, can not find any spte using the host page, then
> >> Accessed/Dirty for host page is missing tracked.
> >> (missing call kvm_set_pfn_accessed and kvm_set_pfn_dirty properly.)
> >>
> >> What's your idea?
> > 
> > 
> > Step 1) Fix kvm_mmu_zap_all's behaviour: introduce lockbreak via
> > spin_needbreak. Use generation numbers so that in case kvm_mmu_zap_all 
> > releases mmu_lock and reacquires it again, only shadow pages 
> > from the generation with which kvm_mmu_zap_all started are zapped (this
> > guarantees forward progress and eventual termination).
> > 
> > kvm_mmu_zap_generation()
> > 	spin_lock(mmu_lock)
> > 	int generation = kvm->arch.mmu_generation;
> > 
> > 	for_each_shadow_page(sp) {
> > 		if (sp->generation == kvm->arch.mmu_generation)
> > 			zap_page(sp)
> > 		if (spin_needbreak(mmu_lock)) {
> > 			kvm->arch.mmu_generation++;
> > 			cond_resched_lock(mmu_lock);
> > 		}
> > 	}
> > 
> > kvm_mmu_zap_all()
> > 	spin_lock(mmu_lock)
> > 	for_each_shadow_page(sp) {
> > 		if (spin_needbreak(mmu_lock)) {
> > 			cond_resched_lock(mmu_lock);
> > 		}
> > 	}
> > 
> > Use kvm_mmu_zap_generation for kvm_arch_flush_shadow_memslot.
> > Use kvm_mmu_zap_all for kvm_mmu_notifier_release,kvm_destroy_vm.
> > 
> > This addresses the main problem: excessively long hold times 
> > of kvm_mmu_zap_all with very large guests.
> > 
> > Do you see any problem with this logic? This was what i was thinking 
> > we agreed.
> 
> No. I understand it and it can work.
> 
> Actually, it is similar with Gleb's idea that "zapping stale shadow pages
> (and uses lock break technique)", after some discussion, we thought "only zap
> shadow pages that are reachable from the slot's rmap" is better, that is this
> patchset does.
> (https://lkml.org/lkml/2013/4/23/73)
> 
> > 
> > Step 2) Show that the optimization to zap only the roots is worthwhile
> > via benchmarking, and implement it.
> 
> This is what i am confused. I can not understand how "zap only the roots"
> works. You mean these change?
> 
> kvm_mmu_zap_generation()
>  	spin_lock(mmu_lock)
>  	int generation = kvm->arch.mmu_generation;
> 
>  	for_each_shadow_page(sp) {
> 		/* Change here. */
> => 		if ((sp->generation == kvm->arch.mmu_generation) &&
> =>		      sp->root_count)
>  			zap_page(sp)
> 
>  		if (spin_needbreak(mmu_lock)) {
>  			kvm->arch.mmu_generation++;
>  			cond_resched_lock(mmu_lock);
>  		}
>  	}
> 
> If we do this, there will have shadow pages that are linked to invalid memslot's
> rmap. How do we handle these pages and the mmu-notify issue?
> 
> Thanks!

By "zap only roots" i mean zapping roots plus generation number on
shadow pages. But this as a second step, after it has been demonstrated
its worthwhile.

  parent reply	other threads:[~2013-05-06 19:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-27  3:13 [PATCH v4 0/6] KVM: MMU: fast zap all shadow pages Xiao Guangrong
2013-04-27  3:13 ` [PATCH v4 1/6] KVM: MMU: drop unnecessary kvm_reload_remote_mmus Xiao Guangrong
2013-04-27  3:13 ` [PATCH v4 2/6] KVM: x86: introduce memslot_set_lpage_disallowed Xiao Guangrong
2013-05-03  2:10   ` Takuya Yoshikawa
2013-05-03  5:55     ` Xiao Guangrong
2013-04-27  3:13 ` [PATCH v4 3/6] KVM: MMU: introduce kvm_clear_all_lpage_info Xiao Guangrong
2013-05-03  2:15   ` Takuya Yoshikawa
2013-05-03  5:57     ` Xiao Guangrong
2013-04-27  3:13 ` [PATCH v4 4/6] KVM: MMU: fast invalid all shadow pages Xiao Guangrong
2013-05-03  1:05   ` Marcelo Tosatti
2013-05-03  5:52     ` Xiao Guangrong
2013-05-03 15:53       ` Marcelo Tosatti
2013-05-03 16:51         ` Xiao Guangrong
2013-05-04  0:52           ` Marcelo Tosatti
2013-05-04  0:56             ` Marcelo Tosatti
2013-05-06  3:39             ` Xiao Guangrong
2013-05-06 12:36               ` Gleb Natapov
2013-05-06 13:10                 ` Xiao Guangrong
2013-05-06 17:24                   ` Gleb Natapov
2013-05-06 17:45                     ` Xiao Guangrong
2013-05-07  8:58                       ` Gleb Natapov
2013-05-07  9:41                         ` Xiao Guangrong
2013-05-07 10:00                           ` Gleb Natapov
2013-05-07 14:33                             ` Marcelo Tosatti
2013-05-07 14:56                               ` Gleb Natapov
2013-05-07 15:09                                 ` Marcelo Tosatti
2013-05-08 10:41                                   ` Gleb Natapov
2013-05-06 19:50               ` Marcelo Tosatti [this message]
2013-05-07  3:39                 ` Xiao Guangrong
2013-05-07 14:42                   ` Marcelo Tosatti
2013-05-03  2:27   ` Takuya Yoshikawa
2013-05-03  6:00     ` Xiao Guangrong
2013-04-27  3:13 ` [PATCH v4 5/6] KVM: x86: use the fast way to invalid all pages Xiao Guangrong
2013-04-27  3:13 ` [PATCH v4 6/6] KVM: MMU: make kvm_mmu_zap_all preemptable 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=20130506195022.GA5706@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=avi.kivity@gmail.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=takuya.yoshikawa@gmail.com \
    --cc=xiaoguangrong@linux.vnet.ibm.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