From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ2Q0-0008C9-Eu for qemu-devel@nongnu.org; Fri, 20 Mar 2015 15:17:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZ2Pz-0002WW-IY for qemu-devel@nongnu.org; Fri, 20 Mar 2015 15:17:16 -0400 From: John Snow Date: Fri, 20 Mar 2015 15:16:49 -0400 Message-Id: <1426879023-18151-7-git-send-email-jsnow@redhat.com> In-Reply-To: <1426879023-18151-1-git-send-email-jsnow@redhat.com> References: <1426879023-18151-1-git-send-email-jsnow@redhat.com> Subject: [Qemu-devel] [PATCH v4 06/20] 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 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