Date: Sat, 22 Dec 2012 14:40:39 -0800 From: Tim Kientzle <tim@kientzle.com> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: Jason Evans <jasone@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: jemalloc enhancement for small-memory systems Message-ID: <75ECE5AB-9276-44BA-84D7-56EF6BDC3984@kientzle.com> In-Reply-To: <1356204505.1129.21.camel@revolution.hippie.lan> References: <1356204505.1129.21.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 22, 2012, at 11:28 AM, Ian Lepore wrote: > When a daemon such as watchdogd uses mlockall(2) on a small-memory > embedded system, it can end up wiring much of the available ram = because > jemalloc allocates large chunks of vmspace by default. More = background > info on this can be found in this thread: >=20 > = http://lists.freebsd.org/pipermail/freebsd-embedded/2012-November/001679.h= tml >=20 > It's hard to tune jemalloc's allocation behavior for this in a > machine-independent way because the minimum chunk size depends on > PAGE_SIZE and other factors internal to jemalloc. I've created a = patch > that addresses this by defining that lg_chunk:0 is implicitly a = request > to set the chunk size to the smallest value allowable for the machine > it's running on. The patch is attached to this PR... >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D174641 >=20 > Jason, could you please review this and consider incorporating it into > jemalloc? Or let us know if there's a better way to handle this > situation. Would it be feasible for jemalloc to initially allocate small blocks (to not over-allocate for small programs and systems with small RAM) and then allocate successively larger blocks as the program requires more memory? Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75ECE5AB-9276-44BA-84D7-56EF6BDC3984>