On 01/23/2013 09:28 PM, Takuya Yoshikawa wrote: > On Wed, 23 Jan 2013 18:44:52 +0800 > Xiao Guangrong <xiaoguangrong@xxxxxxxxxxxxxxxxxx> 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.) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
