From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 17:08:50 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89D0316A469 for ; Tue, 19 Feb 2008 17:08:50 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB7013C461 for ; Tue, 19 Feb 2008 17:08:50 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.201] (unknown [192.168.168.201]) by canonware.com (Postfix) with ESMTP id 72195129831; Tue, 19 Feb 2008 09:13:02 -0800 (PST) Message-ID: <47BB0D29.5080403@freebsd.org> Date: Tue, 19 Feb 2008 09:08:57 -0800 From: Jason Evans User-Agent: Thunderbird 1.5.0.12 (X11/20080213) MIME-Version: 1.0 To: Igor Sysoev References: <20080219151809.GF57366@rambler-co.ru> In-Reply-To: <20080219151809.GF57366@rambler-co.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: malloc(3) ignores RLIMIT_DATA 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, 19 Feb 2008 17:08:50 -0000 Igor Sysoev wrote: > malloc(3) in FreeBSD 7 uses mmap() (then sbrk() on 32-bit platform) > and ignores RLIMIT_DATA. FreeBSD 8's malloc() can be configured > to use sbrk() only ("Dm"), but default setting is "DM". I plan to merge these changes to RELENG_7 shortly after FreeBSD 7.0 is released. As for the default, "DM", there is a strong argument that malloc() should try hard to succeed, and only fail prematurely if the user has added constraints via resource limits. Unfortunately, RELENG_7_0 will not have the proper MALLOC_OPTIONS support to disable mmap()-based allocation, but the release engineers prudently deemed the necessary malloc(3) changes too risky so late in the release cycle. > As sbrk() is less preferable because of framentation and race conditions, > why not to create mmap() flag MMAP_DSS to check RLIMIT_DATA and to use it > in malloc(3) ? There has been general agreement among the people I've discussed this issue with that the correct solution is to add a separate resource limit for anonymously mapped memory, which would provide capabilities similar to what your suggestion would provide. Jason