From owner-freebsd-arch@FreeBSD.ORG Sat Dec 22 23:04:39 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43D96B05; Sat, 22 Dec 2012 23:04:39 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C11D08FC0A; Sat, 22 Dec 2012 23:04:38 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBMN4boL054862; Sat, 22 Dec 2012 16:04:37 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBMN4YqS069151; Sat, 22 Dec 2012 16:04:34 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: jemalloc enhancement for small-memory systems From: Ian Lepore To: Tim Kientzle In-Reply-To: <75ECE5AB-9276-44BA-84D7-56EF6BDC3984@kientzle.com> References: <1356204505.1129.21.camel@revolution.hippie.lan> <75ECE5AB-9276-44BA-84D7-56EF6BDC3984@kientzle.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Dec 2012 16:04:34 -0700 Message-ID: <1356217474.1129.40.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Jason Evans , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 23:04:39 -0000 On Sat, 2012-12-22 at 14:40 -0800, Tim Kientzle wrote: > 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? > > Tim It might be nice if it used sysconf(3) to see how much memory is available on the system and auto-tune accordingly. If the machine only has 32mb it's probably not useful to allocate in 8mb chunks. On the other hand, since it's normally only allocating virtual address space, over-allocating should be harmless. It's the addition of mlockall() that makes it problematic, so it's not too onerous to require a program using mlockall() to specifically tune its use of jemalloc. -- Ian