[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [PATCH v4 04/17] dirty-bitmap: Drop unused
Re: [Qemu-block] [Qemu-devel] [PATCH v4 04/17] dirty-bitmap: Drop unused functions
Fri, 7 Jul 2017 16:05:44 +0300
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
07.07.2017 11:44, Vladimir Sementsov-Ogievskiy wrote:
07.07.2017 02:43, John Snow wrote:
On 07/03/2017 11:10 AM, Eric Blake wrote:
We had several functions that no one is currently using, and which
use sector-based interfaces. I'm trying to convert towards byte-based
interfaces, so it's easier to just drop the unused functions:
Signed-off-by: Eric Blake <address@hidden>
Admittedly I forget entirely why some of these are here, or to be more
precise I forget entirely why they are unused as I remember exactly why
we needed them -- but I forget why we merged them without a caller.
Oh well. If they're unused, they're unused, and can be re-added,
especially if we're changing the underpinnings.
I bet my last review on this email used nearly identical wordings.
I'm CCing Vladimir so he has a chance to see that we're removing
functions that he may have wanted to use for his migration series.
Reviewed-by: John Snow <address@hidden>
Meta bitmaps was first approach of my dirty-bitmap migration
realization, and their first realization was in early bitmap-migration
series. However, now my series are based on postcopy approach and meta
bitmaps are not needed.
Current realization of meta bitmaps was started by Fam, he wanted to
use them not only for my migration, but also for persistent bitmap
optimization (to reduce amount of dirt-bitmap data to be saved, to
save only changed parts).
This is still true: we can try to make persistent bitmaps storing more
efficient, using meta bitmaps, but I'm not sure that it is worth doing
and I have no plans on it for now.
Also, I think true way of optimization would be move from hbitmap to
some kind of sparse bitmap, where bitamp is devided into several blocks,
and for each block we can store additional info like
- offset (link to data block in ram)
- present (offset is valid link to corresponding data block, otherwise,
block is not allocated in ram)
- all zeros (data block is not needed, offset is ignored)
- all ones
- not loaded (for lazy persistent bitmap loading, we can load bitmap
blocks on demand)
- changed (for persistent bitmaps - this block should be saved)
[Qemu-block] [PATCH v4 07/17] qcow2: Switch sectors_covered_by_bitmap_cluster() to byte-based, Eric Blake, 2017/07/03
[Qemu-block] [PATCH v4 08/17] dirty-bitmap: Set iterator start by offset, not sector, Eric Blake, 2017/07/03