From owner-freebsd-arch@FreeBSD.ORG Sun Dec 23 20:42:12 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 C5682996 for ; Sun, 23 Dec 2012 20:42:12 +0000 (UTC) (envelope-from eike@inter.net) Received: from daiquiri.ops.eusc.inter.net (daiquiri.ops.eusc.inter.net [84.23.254.156]) by mx1.freebsd.org (Postfix) with ESMTP id 7CA4E8FC0A for ; Sun, 23 Dec 2012 20:42:12 +0000 (UTC) X-Trace: 507c65696b6540736e6166752e64657c39332e3232302e37322e3131307c31546d 72694e2d3030304d62782d57447c31333536323932383034 Received: from daiquiri.ops.eusc.inter.net ([10.156.10.19] helo=localhost) by daiquiri.ops.eusc.inter.net with esmtpsa (Exim 4.76) id 1TmriN-000Mbx-WD; Sun, 23 Dec 2012 21:00:04 +0100 Subject: Re: jemalloc enhancement for small-memory systems Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Eike Dierks In-Reply-To: <1356204505.1129.21.camel@revolution.hippie.lan> Date: Sun, 23 Dec 2012 21:00:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9EDB4DF7-6763-407C-BBCE-02915CDE7005@inter.net> References: <1356204505.1129.21.camel@revolution.hippie.lan> To: freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.1085) X-SA-Exim-Connect-IP: 93.220.72.110 X-SA-Exim-Mail-From: eike@inter.net X-SA-Exim-Scanned: No (on daiquiri.ops.eusc.inter.net); SAEximRunCond expanded to false Cc: jasone@canonware.com 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 20:42:12 -0000 Hi Ian, I'm trying to understand the underlying problem. Looks like you already investigated that. Please tell us more about that. As far as I understand, jemalloc is not that bad at all. but it seems to get into conflict with the use of mlockall in some = situations. We should get Jason Evans in the boat to sort this out. malloc is not an easy task ... I once had the idea that the VM in FreeBSD was somehow build upon the = Mach VM? Is this still true today? How do they cope with this kind of problems in Darwin ~eike On Dec 22, 2012, at 20:28 , 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. >=20 > -- Ian >=20 >=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org"