From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4760 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Proposed approach for malloc to deal with failing brk Date: Mon, 31 Mar 2014 13:05:59 +0200 Message-ID: <20140331110559.GB3034@port70.net> References: <20140331004104.GA15223@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1396263981 22282 80.91.229.3 (31 Mar 2014 11:06:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Mar 2014 11:06:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4764-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 31 13:06:15 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WUa2e-0004ZT-8Y for gllmg-musl@plane.gmane.org; Mon, 31 Mar 2014 13:06:12 +0200 Original-Received: (qmail 21846 invoked by uid 550); 31 Mar 2014 11:06:11 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21838 invoked from network); 31 Mar 2014 11:06:11 -0000 Content-Disposition: inline In-Reply-To: <20140331004104.GA15223@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4760 Archived-At: * Rich Felker [2014-03-30 20:41:04 -0400]: > We want brk. This is not because "brk is faster than mmap", but > because it takes a lot of work to replicate what brk does using mmap, > and there's no hope of making a complex dance of multiple syscalls > equally efficient. My best idea for emulating brk was to mmap a huge another reason to have brk: on some archs there is a TASK_UNMAPPED_BASE limit in the kernel (1G normally) and mmap can only allocate above that a large part of the first 1G is used for brk only (and top 1G is kernel) so an mmap only allocator would limit the malloc space to 2G (at least 32bit arm and mips i think) > Once brk has failed, begin obtaining new blocks to add to the heap via > mmap, with the size carefully chosen: > > MAX(requested_size, PAGE_SIZE<<(mmap_cnt/2)) yes this works, i added a regression test for brk failure