From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEdUa-0002v7-NR for qemu-devel@nongnu.org; Tue, 05 Aug 2014 08:05:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XEdUV-0006Ts-F6 for qemu-devel@nongnu.org; Tue, 05 Aug 2014 08:05:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6169) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEdUV-0006TV-6s for qemu-devel@nongnu.org; Tue, 05 Aug 2014 08:05:19 -0400 Date: Tue, 5 Aug 2014 14:05:37 +0200 From: "Michael S. Tsirkin" Message-ID: <20140805120537.GB13367@redhat.com> References: <1407209598-2572-1-git-send-email-ming.lei@canonical.com> <1407209598-2572-2-git-send-email-ming.lei@canonical.com> <53E0C645.5050106@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53E0C645.5050106@redhat.com> Subject: Re: [Qemu-devel] [PATCH v1 01/17] qemu/obj_pool.h: introduce object allocation pool List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , Peter Maydell , Fam Zheng , Ming Lei , qemu-devel@nongnu.org, Stefan Hajnoczi , Paolo Bonzini On Tue, Aug 05, 2014 at 05:55:49AM -0600, Eric Blake wrote: > On 08/04/2014 09:33 PM, Ming Lei wrote: > > This patch introduces object allocation pool for speeding up > > object allocation in fast path. > > > > Signed-off-by: Ming Lei > > --- > > include/qemu/obj_pool.h | 64 +++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 64 insertions(+) > > create mode 100644 include/qemu/obj_pool.h > > > > diff --git a/include/qemu/obj_pool.h b/include/qemu/obj_pool.h > > new file mode 100644 > > index 0000000..94b5f49 > > --- /dev/null > > +++ b/include/qemu/obj_pool.h > > @@ -0,0 +1,64 @@ > > +#ifndef QEMU_OBJ_POOL_HEAD > > +#define QEMU_OBJ_POOL_HEAD > > Missing copyright boilerplate. According to LICENSE, that makes this > file GPLv2+, but I'd much rather you make it explicit. > > > + > > +typedef struct { > > + unsigned int size; > > + unsigned int cnt; > > size_t feels better for sizes. int may be okay in this case, but > definitely consider if size_t is appropriate. > > > + > > + void **free_obj; > > + int free_idx; > > + > > + char *objs; > > +} ObjPool; > > + > > +static inline void obj_pool_init(ObjPool *op, void *objs_buf, void **free_objs, > > + unsigned int obj_size, unsigned cnt) > > +{ > > + int i; > > + > > + op->objs = (char *)objs_buf; > > Why the cast? This is C, not C++. It's not needed in C++ either, right? > > + op->free_obj = free_objs; > > + op->size = obj_size; > > + op->cnt = cnt; > > + > > + for (i = 0; i < op->cnt; i++) { > > + op->free_obj[i] = (void *)&op->objs[i * op->size]; > > Again, why the cast? > > > > +static inline bool obj_pool_has_obj(ObjPool *op, void *obj) > > +{ > > + return op && (unsigned long)obj >= (unsigned long)&op->objs[0] && > > + (unsigned long)obj <= > > + (unsigned long)&op->objs[(op->cnt - 1) * op->size]; > > uintptr_t, not unsigned long. You are asking for problems on 64-bit > mingw, where unsigned long is 32 bits but uintptr_t is 64 bits. > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >