| Message ID | 1426271419-8277-7-git-send-email-jsnow@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 2015-03-13 at 14:30, John Snow wrote: > As a convenience: between incremental backups, bitmap migrations > and bitmap persistence we seem to need to recalculate these a lot. > > Because the lengths are a little bit-twiddly, let's just solidly > cache them and be done with it. > > Signed-off-by: John Snow <jsnow@redhat.com> > --- > util/hbitmap.c | 4 ++++ > 1 file changed, 4 insertions(+) Reviewed-by: Max Reitz <mreitz@redhat.com>
diff --git a/util/hbitmap.c b/util/hbitmap.c index ab13971..5b78613 100644 --- a/util/hbitmap.c +++ b/util/hbitmap.c @@ -90,6 +90,9 @@ struct HBitmap { * bitmap will still allocate HBITMAP_LEVELS arrays. */ unsigned long *levels[HBITMAP_LEVELS]; + + /* The length of each levels[] array. */ + uint64_t sizes[HBITMAP_LEVELS]; }; /* Advance hbi to the next nonzero word and return it. hbi->pos @@ -384,6 +387,7 @@ HBitmap *hbitmap_alloc(uint64_t size, int granularity) hb->granularity = granularity; for (i = HBITMAP_LEVELS; i-- > 0; ) { size = MAX((size + BITS_PER_LONG - 1) >> BITS_PER_LEVEL, 1); + hb->sizes[i] = size; hb->levels[i] = g_new0(unsigned long, size); }
As a convenience: between incremental backups, bitmap migrations and bitmap persistence we seem to need to recalculate these a lot. Because the lengths are a little bit-twiddly, let's just solidly cache them and be done with it. Signed-off-by: John Snow <jsnow@redhat.com> --- util/hbitmap.c | 4 ++++ 1 file changed, 4 insertions(+)