From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36482) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjG1e-0007Rt-FG for qemu-devel@nongnu.org; Fri, 17 Apr 2015 19:50:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjG1d-0005xH-6R for qemu-devel@nongnu.org; Fri, 17 Apr 2015 19:50:22 -0400 From: John Snow Date: Fri, 17 Apr 2015 19:49:54 -0400 Message-Id: <1429314609-29776-7-git-send-email-jsnow@redhat.com> In-Reply-To: <1429314609-29776-1-git-send-email-jsnow@redhat.com> References: <1429314609-29776-1-git-send-email-jsnow@redhat.com> Subject: [Qemu-devel] [PATCH v6 06/21] hbitmap: cache array lengths List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-block@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, John Snow , qemu-devel@nongnu.org, armbru@redhat.com, vsementsov@parallels.com, stefanha@redhat.com, mreitz@redhat.com 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. Reviewed-by: Max Reitz Reviewed-by: Eric Blake Signed-off-by: John Snow --- util/hbitmap.c | 4 ++++ 1 file changed, 4 insertions(+) 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); } -- 2.1.0