From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: [RFC] Replacing Xen's xmalloc engine and(?) API Date: Sun, 12 Oct 2008 11:03:56 -0700 (PDT) Message-ID: References: <4cefeab80810121044j44687af3s78574b41c7a9ab04@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4cefeab80810121044j44687af3s78574b41c7a9ab04@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Nitin Gupta Cc: Diwaker Gupta , kurt.hackel@oracle.com, "Xen-Devel (E-mail)" , Keir Fraser List-Id: xen-devel@lists.xenproject.org Hi Nitin -- Excellent! Your xvMalloc looks even better! I'll read the code and try it (tomorrow). Keir, is a "GNU Lesser GPL Version 3" license OK for Xen? Thanks, Dan > -----Original Message----- > From: Nitin Gupta [mailto:nitingupta910@gmail.com] > Sent: Sunday, October 12, 2008 11:45 AM > To: Dan Magenheimer > Cc: Keir Fraser; Xen-Devel (E-mail); Diwaker Gupta; Kurt Hackel > Subject: Re: [Xen-devel] [RFC] Replacing Xen's xmalloc engine=20 > and(?) API >=20 >=20 > On Sun, Oct 12, 2008 at 11:01 PM, Dan Magenheimer > wrote: > > > > I'm no slab/slub expert but I think the interface only works > > well with fixed-size objects and when several of the fixed-size > > objects can be crammed into a single page. I have a large set > > of objects that are essentially random in size (but all less > > than or equal to a page). > > >=20 > Using slab for your use case, which requires lot of allocations for > near page-sized objects, is really bad idea. For memory compression > project (compcache) I had very similar requirement. So, I tested > kmalloc which uses slabs of various sizes to allocate various sizes. > As expected its space efficiency was horrible. At least for compcache > workload it used ~40% more memory than TLSF. Please refer: > http://code.google.com/p/compcache/wiki/AllocatorsComparison >=20 > Regarding non-standard TLSF interface, it should be quite simple to > have wrappers around TLSF to have standard malloc/free API. >=20 > Also I recently completed draft implementation of a new allocator - > xvMalloc (based on TLSF) that is specifically suited for allocation > behavior of compcache (I think "difference engine" project has almost > same requirements). > http://code.google.com/p/compcache/wiki/xvMalloc >=20 > Nitin >