From owner-freebsd-current@FreeBSD.ORG Tue Nov 22 15:59:04 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7C94106564A; Tue, 22 Nov 2011 15:59:04 +0000 (UTC) (envelope-from mdounin@mdounin.ru) Received: from mdounin.cust.ramtel.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mx1.freebsd.org (Postfix) with ESMTP id 92D118FC0C; Tue, 22 Nov 2011 15:59:04 +0000 (UTC) Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mdounin.cust.ramtel.ru (Postfix) with ESMTP id 4437F17024; Tue, 22 Nov 2011 19:43:57 +0400 (MSK) Date: Tue, 22 Nov 2011 19:43:57 +0400 From: Maxim Dounin To: Kostik Belousov Message-ID: <20111122154357.GI95664@mdounin.ru> References: <20111122124410.GP50300@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111122124410.GP50300@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: is@nginx.org, arch@freebsd.org, current@freebsd.org Subject: Re: RLIMIT_DATA and malloc(3) use of mmap(2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 15:59:04 -0000 Hello! On Tue, Nov 22, 2011 at 02:44:10PM +0200, Kostik Belousov wrote: > 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'. Just a little clarification for others: currently, there is no way to *safely* limit memory usage of a process while using jemalloc with mmap(). The only thing available is RLIMIT_VMEM, but it's not safe as it may be reached on stack grow (leaving no possibility for an application to handle this). > 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. > > 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. > > Do people consider the facility useful ? Yes, at least some way to safely limit process memory usage is certainly needed. It's a bit sad this isn't enabled by default, but it's probably too late for this. RLIMIT_DATA was (almost) a noop for too long and making it work again to limit all memory allocations will break POLA. > Any comments for the patch itself ? > > http://people.freebsd.org/~kib/misc/map_datalimit.1.patch Patch looks ok for me (though I'm not a VM expert). Another possible aproach would be to introduce separate anonymous (private?) mmap limit, this will allow to do essentially the same thing in a bit more consistent (IMHO) manner. Maxim Dounin