From: Steven Walter <stevenrwalter@gmail.com>
To: musl@lists.openwall.com
Cc: Steven Walter <stevenrwalter@gmail.com>
Subject: [PATCH] malloc/expand_heap.c: really try to use all available memory
Date: Tue, 18 Jul 2017 08:52:59 -0400 [thread overview]
Message-ID: <20170718125259.19932-1-stevenrwalter@gmail.com> (raw)
Previously expand_heap would ask for increasingly larger mmap areas
every time, in order to avoid allocating a bunch of small areas and
fragmenting memory. However, after a point, we may ask for an mmap area
so large that it can't possibly succeed, even though there is still
system memory available. This is particularly likely on a 32-bit system
with gigs of RAM, or else on a no-MMU system with pretty much any amount
of RAM. Without an MMU to make physically-discontiguous pages appear
contigious, the chance of any large mmap succeeding are very low.
To fix this, support decreasing mmap_step once we hit an allocation
failure. We'll try smaller and smaller amounts until we either ask for
a single page or exactly as many pages as we currently need. Only if
that fails do we fail the overall request.
---
src/malloc/expand_heap.c | 27 +++++++++++++++++++--------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/src/malloc/expand_heap.c b/src/malloc/expand_heap.c
index d8c0be7..6a0dae8 100644
--- a/src/malloc/expand_heap.c
+++ b/src/malloc/expand_heap.c
@@ -61,12 +61,23 @@ void *__expand_heap(size_t *pn)
return (void *)(brk-n);
}
- size_t min = (size_t)PAGE_SIZE << mmap_step/2;
- if (n < min) n = min;
- void *area = __mmap(0, n, PROT_READ|PROT_WRITE,
- MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
- if (area == MAP_FAILED) return 0;
- *pn = n;
- mmap_step++;
- return area;
+ while (1) {
+ size_t min = (size_t)PAGE_SIZE << mmap_step/2;
+ size_t size = n;
+ if (size < min) size = min;
+ void *area = __mmap(0, size, PROT_READ|PROT_WRITE,
+ MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
+ if (area != MAP_FAILED) {
+ *pn = size;
+ mmap_step++;
+ return area;
+ }
+
+ // If we asked for a single page (or the exact allocation
+ // amount) and still didn't get it, we're toast
+ if (size == n || mmap_step < 2)
+ return 0;
+
+ mmap_step--;
+ }
}
--
2.7.4
next reply other threads:[~2017-07-18 12:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-18 12:52 Steven Walter [this message]
2017-07-18 17:27 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170718125259.19932-1-stevenrwalter@gmail.com \
--to=stevenrwalter@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).