From: Paolo Bonzini <pbonzini@redhat.com>
To: Umesh Deshpande <udeshpan@redhat.com>
Cc: kvm@vger.kernel.org, quintela@redhat.com, mtosatti@redhat.com
Subject: Re: [RFC PATCH v3 3/4] lock to protect memslots
Date: Mon, 15 Aug 2011 07:10:12 -0700 [thread overview]
Message-ID: <4E4928C4.4020104@redhat.com> (raw)
In-Reply-To: <4E48C078.50109@redhat.com>
On 08/14/2011 11:45 PM, Umesh Deshpande wrote:
>> That's not too good because qemu_get_ram_ptr is a hot path for TCG.
>
> Looks like qemu_get_ram_ptr isn't called from the source side code of
> guest migration.
Right, but since you are accessing the list from both migration and
non-migration threads, qemu_get_ram_ptr needs to take the ram_list lock.
The ram_list and IO thread mutexes together protect the "next" member,
and you need to hold them both when modifying the list.
See the reply to Marcelo for a proposed solution.
Paolo
next prev parent reply other threads:[~2011-08-15 14:10 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 [this message]
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
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=4E4928C4.4020104@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--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.