From owner-freebsd-arch@FreeBSD.ORG Sat Dec 22 19:28:29 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 47F39535; Sat, 22 Dec 2012 19:28:29 +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 0D2DB8FC0C; Sat, 22 Dec 2012 19:28:28 +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 qBMJSRB1052561; Sat, 22 Dec 2012 12:28:28 -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 qBMJSPk0069007; Sat, 22 Dec 2012 12:28:25 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: jemalloc enhancement for small-memory systems From: Ian Lepore To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Dec 2012 12:28:25 -0700 Message-ID: <1356204505.1129.21.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 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 19:28:29 -0000 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. -- Ian