On 03/14/2013 10:39 AM, Marcelo Tosatti wrote: > 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. Hmm? How frequently is of mmu_shrink? Well, it would be heavy sometimes, but is not the case on normal running. How many mmio shdow pages we got in the system? Not many, especially on the virtio supported guest. And, if it is a real problem, it is worthwhile to optimize it since it is more worse for normal page rmap on shadow mmu. I have a idea to avoid holding mmu-lock that i mentioned in the previous mail that is cache generation-number into mmio spte. When zap mmio spte is needed, we can just simply increase the global generation-number. > > 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? Marcelo, I do not persist in it. ;) -- 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
