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>
index | next in thread | previous in thread | raw e-mail
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: > > http://lists.freebsd.org/pipermail/freebsd-embedded/2012-November/001679.html > > 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... > > http://www.freebsd.org/cgi/query-pr.cgi?pr=174641 > > 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? Timhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75ECE5AB-9276-44BA-84D7-56EF6BDC3984>