From owner-freebsd-arch@FreeBSD.ORG Sun Dec 23 17:16:42 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 9EA88979 for ; Sun, 23 Dec 2012 17:16:42 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 656AF8FC0C for ; Sun, 23 Dec 2012 17:16:41 +0000 (UTC) Received: from [192.168.168.12] (70-91-206-178-BusName-SFBA.hfc.comcastbusiness.net [70.91.206.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id BFCD728417; Sun, 23 Dec 2012 09:10:15 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: jemalloc enhancement for small-memory systems From: Jason Evans In-Reply-To: <1356204505.1129.21.camel@revolution.hippie.lan> Date: Sun, 23 Dec 2012 09:10:14 -0800 Message-Id: References: <1356204505.1129.21.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: 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: Sun, 23 Dec 2012 17:16:42 -0000 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. Your approach looks good to me. I just checked in a slightly simpler = patch to the upstream jemalloc repository: = http://www.canonware.com/cgi-bin/gitweb.cgi?p=3Djemalloc.git;a=3Dcommitdif= f;h=3D1bf2743e08ba66cc141e296812839947223e4370 The only real difference is that no warnings are generated for lg_chunk = values between 0 and the minimum supported value. I don't have any short-term plans to update jemalloc in FreeBSD, so feel = free to either commit your patch as is, or update it to merge from the = upstream patch (which will make the next update a bit easier for me). Thanks, Jason=