On Wed, 01 Dec 2010 02:52:08 +0100 Juan Quintela <quintela@xxxxxxxxxx> wrote: > > Since we are planning to do some profiling for these, taking into account > > Kemari, can you please share these information? > > If you see the 0/10 email with this setup, you can see how much time are > we spending on stuff. Just now (for migration, kemari is a bit > different) we have to fix other things first. > Thank you for the information. Sorry, I only had the [9/10] in my kvm mail box and did not notice this [0/10]. > >> >> non-interface-changing ways to reduce this latency, like O(1) write > >> >> protection, or using dirty bits instead of write protection when > >> >> available. > > > > IIUC, O(1) will lazily write protect pages beggining from top level? > > Does this have any impact other than the timing of get_dirty_log()? > > dunno. > > At this point I am trying to: > - get migration with 16-64GB to not having stalls. > - get infrastructure to be able to know what is going on. > > So far, bigger stalls are gone, and discusing what to do next. As > Anthony suggested I run ram_save_live() loop without qemu_mutex, and now > guests get much better interaction, but my current patch (for this) is > just to put qemu_mutex_unlock_iothread()/qemu_mutex_lock_iothread() > around it. I think that we are racey with teh access to the bitmap, but > it was just a test. > > With respect to Kemari, we can discuss what do you need and how you are > going to test, just to not do overlapping work. I see, we've just started to talk about what we have to achieve and what we can expect. I need to talk with Tamura-san about this a bit more before showing some example targets. Thanks, Takuya -- 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
