Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Jan 2013 10:40:15 -0800
From:      Jason Evans <jasone@freebsd.org>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: [rfc] enabling MALLOC_PRODUCTION on -HEAD for now, until jemalloc has been taught to have some run time selectable debug options
Message-ID:  <A803FFD3-E195-43C9-8B5D-24664707584C@freebsd.org>
In-Reply-To: <CAJ-VmomY_jy5s_pgjpjDXZpN54HpKykD-5tWjU6TG6Z7eR=eOQ@mail.gmail.com>
References:  <CAJ-VmomY_jy5s_pgjpjDXZpN54HpKykD-5tWjU6TG6Z7eR=eOQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 19, 2013, at 10:26 PM, 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.

I imported jemalloc 3.3.0 last night, which I think will restore =
non-MALLOC_PRODUCTION performance to roughly what it has been for years. =
 The key change was a patch by Ian Lepore:

	=
http://www.canonware.com/cgi-bin/gitweb.cgi?p=3Djemalloc.git;a=3Dcommitdif=
f;h=3D14a2c6a698a207ac3f3825443cf3441c8842e990

In practice, the zeroed memory validation should no longer execute at =
all on FreeBSD due to madvise(...MADV_FREE) not guaranteeing zeroed =
memory.

I don't know how significant the impact will be on constrained/older =
systems, but for the many buildworld repetitions I did during testing it =
improved throughput by >1.5X.  With this change in place, I'm not keen =
on enabling MALLOC_PRODUCTION by default, because the assertions are =
useful both for detecting bugs in jemalloc (heaven forbid), and for =
indicating that crashes within jemalloc are application errors.  The =
only other significant source of overhead I'm aware of is junk filling, =
which we've had enabled by default on -current for ages, probably since =
the introduction of phkmalloc.  If you don't like it:

	ln -s 'junk:false' /etc/malloc.conf

If a substantial performance difference remains for you =
(MALLOC_PRODUCTION vs non-MALLOC_PRODUCTION with junk:false set), please =
let me know.

Thanks,
Jason=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A803FFD3-E195-43C9-8B5D-24664707584C>