[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140331110559.GB3034@port70.net>
Date: Mon, 31 Mar 2014 13:05:59 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Proposed approach for malloc to deal with failing brk
* Rich Felker <dalias@...ifal.cx> [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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
