All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.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: Wed, 8 May 2013 13:41:00 +0300	[thread overview]
Message-ID: <20130508104100.GU12349@redhat.com> (raw)
In-Reply-To: <20130507150929.GA8118@amt.cnet>

On Tue, May 07, 2013 at 12:09:29PM -0300, Marcelo Tosatti wrote:
> On Tue, May 07, 2013 at 05:56:08PM +0300, Gleb Natapov wrote:
> > > > Yes, I am missing what Marcelo means there too. We cannot free memslot
> > > > until we unmap its rmap one way or the other.
> > > 
> > > I do not understand what are you optimizing for, given the four possible
> > > cases we discussed at
> > > 
> > > https://lkml.org/lkml/2013/4/18/280
> > > 
> > We are optimizing mmu_lock holding time for all of those cases.
> > 
> > But you cannot just "zap roots + sp gen number increase." on slot
> > deletion because you need to transfer access/dirty information from rmap
> > that is going to be deleted to actual page before
> > kvm_set_memory_region() returns to a caller.
> > 
> > > That is, why a simple for_each_all_shadow_page(zap_page) is not sufficient.
> > With a lock break? It is. We tried to optimize that by zapping only pages
> > that reference memslot that is going to be deleted and zap all other
> > later when recycling old sps, but if you think this is premature
> > optimization I am fine with it.
> 
> If it can be shown that its not premature optimization, I am fine with
> it.
> 
> AFAICS all cases are 1) rare and 2) not latency sensitive (as in there
> is no requirement for those cases to finish in a short period of time).
OK, lets start from a simple version. The one that goes through rmap
turned out to be more complicated that we expected.

--
			Gleb.

  reply	other threads:[~2013-05-08 10:41 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 [this message]
2013-05-06 19:50               ` Marcelo Tosatti
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=20130508104100.GU12349@redhat.com \
    --to=gleb@redhat.com \
    --cc=avi.kivity@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.