From owner-freebsd-arch@FreeBSD.ORG Mon Jan 21 19:00:02 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 11290547; Mon, 21 Jan 2013 19:00:02 +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 CC64980C; Mon, 21 Jan 2013 19:00:01 +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 0FBC52842D; Mon, 21 Jan 2013 11:00:01 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [rfc] enabling MALLOC_PRODUCTION on -HEAD for now, until jemalloc has been taught to have some run time selectable debug options From: Jason Evans In-Reply-To: <1358738779.32417.380.camel@revolution.hippie.lan> Date: Mon, 21 Jan 2013 11:00:00 -0800 Message-Id: <96396542-ABE9-44DC-9F3C-9098434E7EE5@freebsd.org> References: <1358738779.32417.380.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: Adrian Chadd , "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: Mon, 21 Jan 2013 19:00:02 -0000 On Jan 20, 2013, at 7:26 PM, Ian Lepore wrote: > On Sat, 2013-01-19 at 22:26 -0800, Adrian Chadd wrote: >> I'd like to enable MALLOC_PRODUCTION on -HEAD. >>=20 >> I'm currently recompiling my libc on this g4 powerbook because the >> -HEAD snapshots don't have it enabled by default; just to get some >> damned decent performance out of this thing. >>=20 >> I'll work with Jason and others (eg Ian) who have a vested interest = in >> trying to get it to run better out of the box, but still have the >> debug options available for people who wish to debug things. >=20 > I've been investigating this today and have some information. >=20 > With MALLOC_PRODUCTION defined there is no problem, even on small > embedded systems. Without MALLOC_PRODUCTION we've basically got two > problems: >=20 > * Every program has a minimum resident size of about 8MiB, and > that's fatal on a small-memory embedded system. > * Performance is bad. This is at least in part due to the = expense > of faulting in 8MiB of zeroed pages, and that's especially > noticible in utilities that should be small and fast. There > could be other causes as well. >=20 > I think I've tracked the cause of the 8MiB resident size to a = particular > sanity check, which validates whether memory that was supposed to have > been zeroed actually was. I think this check makes sense in some = cases, > and not in others. It almost certainly doesn't make sense if the = memory > was freshly obtained from mmap(). Now I remember planning to remove the zeroed memory validation because = of its high cost, but deciding otherwise at the last moment. Literally = the day before I released jemalloc 3.0.0, the validation code caught = this (in the context of FreeBSD's libc): Fix large calloc() zeroing bugs. = http://www.canonware.com/cgi-bin/gitweb.cgi?p=3Djemalloc.git;a=3Dcommitdif= f;h=3Dd8ceef6c5558fdab8f9448376ae065a9e5ffcbdd Since 3.0.0 though there has been some refactoring that makes it = feasible (and clean) to move the validation code from chunk_alloc() to = chunk_recycle(). Ian sent me such a patch (better than the one I would = have come up with myself) that I will test and integrate upstream. In = the meanwhile I think we should try Ian's patch before resorting to = MALLOC_PRODUCTION. Jason=