On Thu, Mar 14, 2013 at 11:26:41AM +0900, Takuya Yoshikawa wrote: > On Wed, 13 Mar 2013 22:58:21 -0300 > Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: > > > > > In zap_spte, don't we need to search the pointer to be removed from the > > > > global mmio-rmap list? How long can that list be? > > > > > > It is not bad. On softmmu, the rmap list has already been long more than 300. > > > On hardmmu, normally the mmio spte is not frequently zapped (just set not clear). > > mmu_shrink() is an exception. > > > > > > > The worst case is zap-all-mmio-spte that removes all mmio-spte. This operation > > > can be speed up after applying my previous patch: > > > KVM: MMU: fast drop all spte on the pte_list > > My point is other code may need to care more about latency. > > Zapping all mmio sptes can happen only when changing memory regions: > not so latency severe but should be reasonably fast not to hold > mmu_lock for a (too) long time. > > Compared to that, mmu_shrink() may be called any time and adding > more work to it should be avoided IMO. It should return ASAP. Good point. > In general, we should try hard to keep ourselves from affecting > unrelated code path for optimizing something. The global pte > list is something which can affect many code paths in the future. > > > So, I'm fine with trying mmio-rmap once we can actually measure > very long mmu_lock hold time by traversing shadow pages. > > How about applying this first and then see the effect on big guests? Works for me. Xiao? -- 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
