Re: [PATCH 09/10] Exit loop if we have been there too long

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux