[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 4/6] block/dirty-bitmap: explicitly lock bitm
From: |
John Snow |
Subject: |
Re: [Qemu-devel] [PATCH v2 4/6] block/dirty-bitmap: explicitly lock bitmaps with successors |
Date: |
Mon, 18 Feb 2019 17:13:16 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 |
On 2/18/19 11:52 AM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> Instead of implying a locked status, make it explicit.
>
> locked interferes with bitmap mutex, so may be better "qmp_locked state", but
> not sure.
>
I agree that "locked" has too many meanings, so in patch 5 I start using
the term "busy" instead.
>> Now, bitmaps in use by migration, NBD or backup operations
>> are all treated the same way with the same code paths.
>>
>> Signed-off-by: John Snow <address@hidden>
>> Reviewed-by: Eric Blake <address@hidden>
>
> Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
>
> Hmm. Isn't it better to make successor-related staff unrelated to locking at
> all?
Maybe -- but it doesn't make sense to allow users to modify bitmaps that
have a successor because we know it's definitely busy. I'll take a
further cleanup patch if you think it's better -- just be careful to
make sure that any interface calls will work gracefully with a bitmap
with a successor.
> So, backup will call set_qmp_locked like others? And then do create_successor,
> abdicate, reclaim, whatever it wants, and finally set_qmp_locked(false) ?
> To make it work even more in the same path. But it may be done separately, if
> we
> want.
>
- [Qemu-devel] [PATCH v2 3/6] block/dirty-bitmap: change semantics of enabled predicate, (continued)