Date: Sat, 03 Dec 2005 16:26:02 +0800 From: David Xu <davidxu@freebsd.org> To: Jason Evans <jasone@canonware.com> Cc: current@freebsd.org Subject: Re: New libc malloc patch Message-ID: <4391569A.7080808@freebsd.org> In-Reply-To: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> References: <B6653214-2181-4342-854D-323979D23EE8@canonware.com> <Pine.LNX.4.53.0511291121360.27754@regurgitate.ugcs.caltech.edu> <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason Evans wrote: > On Nov 29, 2005, at 12:06 PM, Jon Dama wrote: > >> There exists a problem right now--localized to i386 and any other arch >> based on 32-bit pointers: address space is simply too scarce. >> >> Your decision to switch to using mmap as the exclusive source of malloc >> buckets is admirable for its modernity but it simply cannot stand unless >> someone steps up to change the way mmap and brk interact within the >> kernel. > > > There's a new version of the patch available at: > > http://www.canonware.com/~jasone/jemalloc/jemalloc_20051202b.diff > > This version of the patch adds the following: > > * Prefer to use sbrk() rather than mmap() for the 32-bit platforms. > > * Lazily create arenas, so that single-threaded applications don't > dedicate space to arenas they never use. > > * Add the '*' and '/' MALLOC_OPTIONS flags, which allow control over > the number of arenas. > > As of this patch, all of the issues that were brought to my attention > have been addressed. This is a good time for additional review and > serious benchmarking. > > Thanks, > Jason I have a question about mutex used in the patch, you are using a spin loop, isn't it suboptimal ? and a thread library like libpthread supports static priority scheduling, this mutex does not work, it will causes a dead lock, if a lower priority thread locked the mutex, and preempted by a higher priority thread, and the higher priority thread also calls malloc, it will spin there to wait lower priority thread to complete, but that will never happen. David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4391569A.7080808>