All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Cc: Takuya Yoshikawa <yoshikawa_takuya_b1@lab.ntt.co.jp>,
	mtosatti@redhat.com, gleb@redhat.com, kvm@vger.kernel.org
Subject: Re: [PATCH 0/8] KVM: Reduce mmu_lock hold time when zapping mmu pages
Date: Wed, 23 Jan 2013 21:45:23 +0800	[thread overview]
Message-ID: <50FFE973.30709@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130123222846.05bfc05a91ee133bd25981d6@gmail.com>

On 01/23/2013 09:28 PM, Takuya Yoshikawa wrote:
> On Wed, 23 Jan 2013 18:44:52 +0800
> Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> wrote:
> 
>> On 01/23/2013 06:12 PM, Takuya Yoshikawa wrote:
>>> This patch set mitigates another mmu_lock hold time issue.  Although
>>> this is not enough and I'm thinking of additional work already, this
>>> alone can reduce the lock hold time to some extent.
>>>
>>
>> It is not worth doing this kind of complex thing, usually, only a few pages on
>> the invalid list. The *really* heavily case is kvm_mmu_zap_all() which can be speeded
>> up by using generation number, this is a todo work in kvm wiki:
> 
> I don't think this is so complex.  This is a basic programming technique
> using linked lists.

I just consider that only a few page exist on the invalid list, no worth introducing
this.

> 
> The current code which deletes the two link nodes in different functions
> looks unnatural to me: traversing the sp->link nodes forces us to break
> the loop and sp->hash_link nodes alone is allowed to continue ...
> 
> Making each function semantically clear should be more important than
> other things.
> 

The reason the code like this is, we have lockless shadow page walker.

> But maybe a matter of taste, so I'll wait for the maintainers' comments.
> 
>> http://www.linux-kvm.org/page/TODO: O(1) mmu invalidation using a generation number
>>
>> I am doing this work for some weeks and will post the patch out during these days.
> 
> I remember that Avi originally wrote the idea of introducing the
> generation of mmu pages in his other work.
> 

Whatever the original consideration is, the idea can speed up mmu invalidation a lot.
(Actually, i mentioned this idea to you when discussion fast write protect long time ago.)



  reply	other threads:[~2013-01-23 13:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-23 10:12 [PATCH 0/8] KVM: Reduce mmu_lock hold time when zapping mmu pages Takuya Yoshikawa
2013-01-23 10:13 ` [PATCH 1/8] KVM: MMU: Fix and clean up for_each_gfn_* macros Takuya Yoshikawa
2013-01-28 12:24   ` Gleb Natapov
2013-01-28 12:29     ` Takuya Yoshikawa
2013-01-23 10:13 ` [PATCH 2/8] KVM: MMU: Use list_for_each_entry_safe in kvm_mmu_commit_zap_page() Takuya Yoshikawa
2013-01-23 10:14 ` [PATCH 3/8] KVM: MMU: Add a parameter to kvm_mmu_prepare_zap_page() to update the next position Takuya Yoshikawa
2013-01-23 10:15 ` [PATCH 4/8] KVM: MMU: Introduce for_each_gfn_indirect_valid_sp_safe macro Takuya Yoshikawa
2013-01-23 10:16 ` [PATCH 5/8] KVM: MMU: Delete hash_link node in kvm_mmu_prepare_zap_page() Takuya Yoshikawa
2013-01-23 10:16 ` [PATCH 6/8] KVM: MMU: Introduce free_zapped_mmu_pages() for freeing mmu pages in a list Takuya Yoshikawa
2013-01-23 10:17 ` [PATCH 7/8] KVM: MMU: Split out free_zapped_mmu_pages() from kvm_mmu_commit_zap_page() Takuya Yoshikawa
2013-01-23 10:18 ` [PATCH 8/8] KVM: MMU: Move free_zapped_mmu_pages() out of the protection of mmu_lock Takuya Yoshikawa
2013-02-04 13:50   ` Marcelo Tosatti
2013-02-05  2:21     ` Takuya Yoshikawa
2013-01-23 10:44 ` [PATCH 0/8] KVM: Reduce mmu_lock hold time when zapping mmu pages Xiao Guangrong
2013-01-23 13:28   ` Takuya Yoshikawa
2013-01-23 13:45     ` Xiao Guangrong [this message]
2013-01-23 14:49       ` Takuya Yoshikawa
2013-01-23 15:45         ` Xiao Guangrong
2013-02-04 13:42   ` Marcelo Tosatti
2013-02-05  5:30     ` Xiao Guangrong
2013-02-04 13:29 ` Marcelo Tosatti

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=50FFE973.30709@linux.vnet.ibm.com \
    --to=xiaoguangrong@linux.vnet.ibm.com \
    --cc=gleb@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=takuya.yoshikawa@gmail.com \
    --cc=yoshikawa_takuya_b1@lab.ntt.co.jp \
    /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.