From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkeGv-00013t-Ka for qemu-devel@nongnu.org; Mon, 17 Dec 2012 12:14:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkeGs-0004TQ-Vh for qemu-devel@nongnu.org; Mon, 17 Dec 2012 12:14:33 -0500 Received: from qmta09.emeryville.ca.mail.comcast.net ([76.96.30.96]:55588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkeGs-0004T7-Lv for qemu-devel@nongnu.org; Mon, 17 Dec 2012 12:14:30 -0500 Message-ID: <50CF52F2.60102@redhat.com> Date: Mon, 17 Dec 2012 10:14:26 -0700 From: Eric Blake MIME-Version: 1.0 References: <1355319999-30627-1-git-send-email-pbonzini@redhat.com> <1355319999-30627-15-git-send-email-pbonzini@redhat.com> In-Reply-To: <1355319999-30627-15-git-send-email-pbonzini@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig36D3823392E91B7FC5257610" Subject: Re: [Qemu-devel] [PATCH 14/20] hbitmap: add hbitmap_alloc_with_data and hbitmap_required_size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig36D3823392E91B7FC5257610 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/12/2012 06:46 AM, Paolo Bonzini wrote: > Signed-off-by: Paolo Bonzini > --- > hbitmap.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++--------= -- > hbitmap.h | 25 +++++++++++++++++++++++++ > 2 files changed, 72 insertions(+), 10 deletions(-) When using hbitmap_alloc_with_data, must the user pass in all 0 data, or do you do a one-time slow pass over the passed-in data to populate the remaining layers of the hbitmap to allow faster traversal later? > +HBitmap *hbitmap_alloc_with_data(uint64_t size, int granularity, void = *data) > +{ > + HBitmap *hb =3D g_malloc0(sizeof(struct HBitmap)); > + unsigned i; > + > + hb->size =3D hbitmap_round_size(size, granularity); > hb->granularity =3D granularity; > + hb->last_level_allocated =3D (data =3D=3D NULL); > + > for (i =3D HBITMAP_LEVELS; i-- > 0; ) { > - size =3D MAX((size + BITS_PER_LONG - 1) >> BITS_PER_LEVEL, 1);= > - hb->levels[i] =3D g_malloc0(size * sizeof(unsigned long)); > + if (data =3D=3D NULL) { > + data =3D g_malloc0(hbitmap_required_size(size, granularity= )); > + } > + hb->levels[i] =3D data; > + data =3D NULL; > + granularity +=3D BITS_PER_LEVEL; > } > =20 > /* We necessarily have free bits in level 0 due to the definition > * of HBITMAP_LEVELS, so use one for a sentinel. This speeds up > * hbitmap_iter_skip_words. > */ > - assert(size =3D=3D 1); > + assert(hbitmap_required_size(size, granularity) =3D=3D sizeof(unsi= gned long)); > hb->levels[0][0] |=3D 1UL << (BITS_PER_LONG - 1); > return hb; > } Based on the implementation, you aren't inspecting the contents of data. > +/** > + * hbitmap_alloc_with_data: > + * @size: Number of bits in the bitmap. > + * @granularity: Granularity of the bitmap. > + * @data: Pointer to a data block that will be used for the bottom lev= el > + * of the HBitmap. > + * > + * Allocate a new HBitmap, using a client-provided data block for the > + * actual bitmap and allocating memory only for the compressed levels.= > + * If @data is NULL, this function is equivalent to @hbitmap_alloc. > + */ > +HBitmap *hbitmap_alloc_with_data(uint64_t size, int granularity, void = *data); But this documentation didn't mention that the caller must pass in all 0s= =2E --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig36D3823392E91B7FC5257610 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBCAAGBQJQz1LyAAoJEKeha0olJ0NqDS0IAIFa3I28mSbi5POrl85muFu5 TLUTeSA6E5mBDJCyW8Ybpyp/a35RUs/ErYJHJ7H+qkIixohi26GZgQZ88IeK/hgB cbdYAhLt8RVKZ5qdNvUgRZTnOQudWybcSWB2VBKj7DhmEscVkhS840XvVH8CqJaN 7ZJwxq8Vfgo5ARhnBYR/9FjmhCoxpYvOJhoowbQ47T7ed7rDHwzWI1KBDJDT40z8 i6FPvCkqD4x4Ml3XecGpX4q5MqDI/tvBRR5v3ET+K2vgbEzGHuD8BV78bRtrkM0j Se0OXSYTdK3KWlVOD1uCBdWvH45WvGr7HnEuiRLEbuEfrbULJDsW/xQA9dwnDn8= =vqQN -----END PGP SIGNATURE----- --------------enig36D3823392E91B7FC5257610--