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
On Tue, May 07, 2013 at 01:45:52AM +0800, Xiao Guangrong wrote:
On 05/07/2013 01:24 AM, Gleb Natapov wrote:
On Mon, May 06, 2013 at 09:10:11PM +0800, Xiao Guangrong wrote:
On 05/06/2013 08:36 PM, Gleb Natapov wrote:
Step 1) Fix kvm_mmu_zap_all's behaviour: introduce lockbreak via
On 05/07/2013 04:58 PM, Gleb Natapov wrote:
On Tue, May 07, 2013 at 01:45:52AM +0800, Xiao Guangrong wrote:
On 05/07/2013 01:24 AM, Gleb Natapov wrote:
On Mon, May 06, 2013 at 09:10:11PM +0800, Xiao Guangrong wrote:
On 05/06/2013 08:36 PM, Gleb Natapov wrote:
Step 1) Fix kvm_mmu_zap_all's
On Tue, May 07, 2013 at 05:41:35PM +0800, Xiao Guangrong wrote:
On 05/07/2013 04:58 PM, Gleb Natapov wrote:
On Tue, May 07, 2013 at 01:45:52AM +0800, Xiao Guangrong wrote:
On 05/07/2013 01:24 AM, Gleb Natapov wrote:
On Mon, May 06, 2013 at 09:10:11PM +0800, Xiao Guangrong wrote:
On
On Tue, May 07, 2013 at 01:00:51PM +0300, Gleb Natapov wrote:
On Tue, May 07, 2013 at 05:41:35PM +0800, Xiao Guangrong wrote:
On 05/07/2013 04:58 PM, Gleb Natapov wrote:
On Tue, May 07, 2013 at 01:45:52AM +0800, Xiao Guangrong wrote:
On 05/07/2013 01:24 AM, Gleb Natapov wrote:
On Mon,
On Tue, May 07, 2013 at 11:39:59AM +0800, Xiao Guangrong wrote:
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
On Tue, May 07, 2013 at 11:33:29AM -0300, Marcelo Tosatti wrote:
On Tue, May 07, 2013 at 01:00:51PM +0300, Gleb Natapov wrote:
On Tue, May 07, 2013 at 05:41:35PM +0800, Xiao Guangrong wrote:
On 05/07/2013 04:58 PM, Gleb Natapov wrote:
On Tue, May 07, 2013 at 01:45:52AM +0800, Xiao
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
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
On 05/06/2013 08:36 PM, Gleb Natapov wrote:
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
On Mon, May 06, 2013 at 09:10:11PM +0800, Xiao Guangrong wrote:
On 05/06/2013 08:36 PM, Gleb Natapov wrote:
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,
On 05/07/2013 01:24 AM, Gleb Natapov wrote:
On Mon, May 06, 2013 at 09:10:11PM +0800, Xiao Guangrong wrote:
On 05/06/2013 08:36 PM, Gleb Natapov wrote:
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
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
On 05/07/2013 03:50 AM, Marcelo Tosatti wrote:
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
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
On 05/03/2013 10:27 AM, Takuya Yoshikawa wrote:
On Sat, 27 Apr 2013 11:13:20 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
+/*
+ * Fast invalid all shadow pages belong to @slot.
+ *
+ * @slot != NULL means the invalidation is caused the memslot specified
+ * by @slot is
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
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
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.
+ *
On Fri, May 03, 2013 at 09:52:01PM -0300, 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:
On Sat, Apr 27, 2013 at 11:13:20AM +0800, Xiao Guangrong wrote:
The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
walk and zap all shadow pages one by one, also it need to zap all guest
page's rmap and all shadow page's parent spte list. Particularly, things
become worse
On Sat, 27 Apr 2013 11:13:20 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com 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
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
The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
walk and zap all shadow pages one by one, also it need to zap all guest
page's rmap and all shadow page's parent spte list. Particularly, things
become worse if guest uses more memory or vcpus. It is not good for
scalability.
24 matches
Mail list logo