Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Dec 2012 09:10:14 -0800
From:      Jason Evans <jasone@freebsd.org>
To:        Ian Lepore <freebsd@damnhippie.dyndns.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: jemalloc enhancement for small-memory systems
Message-ID:  <ED3C177A-C685-4FAA-9853-82A6B24617E8@freebsd.org>
In-Reply-To: <1356204505.1129.21.camel@revolution.hippie.lan>
References:  <1356204505.1129.21.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 22, 2012, at 11:28 AM, Ian Lepore <freebsd@damnhippie.dyndns.org> =
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=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ED3C177A-C685-4FAA-9853-82A6B24617E8>