Date: Tue, 22 Nov 2011 17:49:35 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Maxim Dounin <mdounin@mdounin.ru> Cc: is@nginx.org, arch@freebsd.org, current@freebsd.org Subject: Re: RLIMIT_DATA and malloc(3) use of mmap(2) Message-ID: <20111122154935.GR50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111122154357.GI95664@mdounin.ru> References: <20111122124410.GP50300@deviant.kiev.zoral.com.ua> <20111122154357.GI95664@mdounin.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--ej7tn9G4wHTwOygb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 22, 2011 at 07:43:57PM +0400, Maxim Dounin wrote: > Hello! >=20 > On Tue, Nov 22, 2011 at 02:44:10PM +0200, Kostik Belousov wrote: >=20 > > I was reminded about the patch I wrote for Igor Sysoev some time ago. > > The issue the patch tries to handle is that jemalloc uses mmap() instead > > of sbrk() for pages allocation, and thus RLIMIT_DATA limit is no longer > > effective to put the bounds on the process heap. Since reverting to sbrk > > for such purpose is worse then the issue itself, I proposed a solution > > of 'self-restricting malloc'. >=20 > Just a little clarification for others: currently, there is no way=20 > to *safely* limit memory usage of a process while using jemalloc=20 > with mmap(). >=20 > The only thing available is RLIMIT_VMEM, but it's not safe as it=20 > may be reached on stack grow (leaving no possibility for an=20 > application to handle this). >=20 > > The patch adds a flag MAP_DATALIMIT to the flags argument of mmap(2), > > which instructs the system to account the mapping in the RLIMIT_DATA > > resource count. The malloc(3) also gets new option 'L' to enable > > passing MAP_DATALIMIT to mmap() when allocating pages. By default, > > the 'L' option is not activated. > >=20 > > Now, if user wants to ensure that process heap is restricted by the > > ulimit -d and still use mmap() for jemalloc, he supplies the option > > using any mechanism. The behaviour is voluntaristic, to prevent the > > trashing use RLIMIT_SWAP. > >=20 > > Do people consider the facility useful ? >=20 > Yes, at least some way to safely limit process memory usage is=20 > certainly needed. >=20 > It's a bit sad this isn't enabled by default, but it's probably=20 > too late for this. RLIMIT_DATA was (almost) a noop for too long=20 > and making it work again to limit all memory allocations will=20 > break POLA. >=20 > > Any comments for the patch itself ? > >=20 > > http://people.freebsd.org/~kib/misc/map_datalimit.1.patch >=20 > Patch looks ok for me (though I'm not a VM expert). >=20 > Another possible aproach would be to introduce separate anonymous=20 > (private?) mmap limit, this will allow to do essentially the same=20 > thing in a bit more consistent (IMHO) manner. This is already done in some form as the per-user swap limit. Converting swap limit to the per-process limit raises the architectural questions, due to shadow chains of the backing vm objects. In particular, we have to account the anonymous memory used for backing the changed pages from the writeable private mapping of the files. Similar issues appear due to fork(). Anyway, the patch needs testers before I will push it forward. --ej7tn9G4wHTwOygb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7LxI4ACgkQC3+MBN1Mb4iMIACeKyzYhqGotSkEe2TGFxRtc3f7 Nk8An0DfqopmYU75H0PmQ4ssc4eL42m4 =GU0S -----END PGP SIGNATURE----- --ej7tn9G4wHTwOygb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111122154935.GR50300>