From: Paolo Bonzini <pbonzini@redhat.com>
To: unlisted-recipients:; (no To-header on input)
Cc: Umesh Deshpande <udeshpan@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
kvm@vger.kernel.org, quintela@redhat.com,
Kevin Wolf <kwolf@redhat.com>
Subject: Re: [RFC PATCH v3 3/4] lock to protect memslots
Date: Tue, 16 Aug 2011 00:56:14 -0700 [thread overview]
Message-ID: <4E4A229E.2040209@redhat.com> (raw)
In-Reply-To: <4E4A0AFA.70409@redhat.com>
On 08/15/2011 11:15 PM, Paolo Bonzini wrote:
> On 08/15/2011 01:27 PM, Umesh Deshpande wrote:
>> Yes, the mru list patch would obviate the need of holding the ram_list
>> mutex in qemu_get_ram_ptr.
>
> Feel free to take it and complete it with locking then!
>
>> Also, I was planning to protect the whole migration thread with iothread
>> mutex, and ram_list mutex. (i.e. holding ram_list mutex while sleeping
>> between two iterations, when we release iothread mutex). This will
>> prevent the memslot block removal altogether during the migration. Do
>> you see any problem with this?
>
> No, indeed holding the ram_list mutex through all the migration "fixes"
> the problems with ram_lists removing during migration. I guess whoever
> will implement memory hotplug, will find a way around it. :)
BTW, now that I think of it, do you have ideas on how to do the
migration thread do block migration?
Paolo
next prev parent reply other threads:[~2011-08-16 7:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-11 15:32 [RFC PATCH v3 0/4] Separate thread for VM migration Umesh Deshpande
2011-08-11 15:32 ` [RFC PATCH v3 1/4] separate " Umesh Deshpande
2011-08-11 16:18 ` Paolo Bonzini
2011-08-11 17:36 ` Umesh Deshpande
2011-08-12 6:40 ` Paolo Bonzini
2011-08-11 15:32 ` [RFC PATCH v3 2/4] Making iothread block for migrate_cancel Umesh Deshpande
2011-08-11 15:32 ` [RFC PATCH v3 3/4] lock to protect memslots Umesh Deshpande
2011-08-11 16:20 ` Paolo Bonzini
2011-08-12 6:45 ` Paolo Bonzini
2011-08-15 6:45 ` Umesh Deshpande
2011-08-15 14:10 ` Paolo Bonzini
2011-08-15 7:26 ` Marcelo Tosatti
2011-08-15 14:14 ` Paolo Bonzini
2011-08-15 20:27 ` Umesh Deshpande
2011-08-16 6:15 ` Paolo Bonzini
2011-08-16 7:56 ` Paolo Bonzini [this message]
2011-08-11 15:32 ` [RFC PATCH v3 4/4] Separate migration bitmap Umesh Deshpande
2011-08-11 16:23 ` [RFC PATCH v3 0/4] Separate thread for VM migration Paolo Bonzini
2011-08-11 18:25 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E4A229E.2040209@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=mtosatti@redhat.com \
--cc=quintela@redhat.com \
--cc=udeshpan@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.