[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v4 2/5] ramlist mutex
From: |
Marcelo Tosatti |
Subject: |
Re: [Qemu-devel] [RFC PATCH v4 2/5] ramlist mutex |
Date: |
Tue, 23 Aug 2011 09:16:30 -0300 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Aug 23, 2011 at 01:41:48PM +0200, Paolo Bonzini wrote:
> On 08/23/2011 11:17 AM, Marcelo Tosatti wrote:
> >>>> > typedef struct RAMList {
> >>>> > + QemuMutex mutex;
> >>>> > uint8_t *phys_dirty;
> >>>> > QLIST_HEAD(ram, RAMBlock) blocks;
> >>>> > QLIST_HEAD(, RAMBlock) blocks_mru;
> >>>
> >>> A comment on what the mutex protects would be good.
>
> Indeed, especially because Umesh wanted to use the ramlist+iothread
> combo as a rw-lock: iothread = read-lock for the I/O thread, ramlist
> = read-lock for the migration thread, together = exclusive (write)
> lock. But I think I talked him out of this. :) It's not a bad idea
> in general, it just sounds like overkill in this case.
>
> >And on the lock ordering.
>
> I think when only two locks are involved, we can always assume
> iothread is outer and the other is inner. Do you agree?
>
> Paolo
Yep.
- [Qemu-devel] [RFC PATCH v4 4/5] separate thread for VM migration, (continued)
[Qemu-devel] [RFC PATCH v3 5/5] Making iothread block for migrate_cancel, Umesh Deshpande, 2011/08/16