From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: malloc & uncommitting memory
Date: Thu, 3 Apr 2014 00:43:23 -0400 [thread overview]
Message-ID: <20140403044323.GR26358@brightrain.aerifal.cx> (raw)
In-Reply-To: <20140402210805.GA852@brightrain.aerifal.cx>
On Wed, Apr 02, 2014 at 05:08:05PM -0400, Rich Felker wrote:
> As long as thresholds are chosen right, I don't think this approach
> would be costly from a performance standpoint. But it might have
> consequences for fragmentation. So I'd like to discuss it further, see
> what ideas emerge, and whether it looks reasonable before trying to
> implement anything.
Basically, the way fragmentation can result from having "frozen"
chunks is when small chunks adjacent to them are freed: these free
chunks are unable to be merged with the frozen chunk, so they get
reused for small allocations despite being adjacent to a large free
(albeit frozen) region.
I see several possible ways to reduce or avoid this:
1. Always leave large padding (large enough to stay in bin-63) on both
sides of the frozen chunk when freezing. This would force adjacent
freed chunks to get merged into a bin-63 chunk, preventing them
from getting used for small allocations unless nothing smaller were
available. However, they could still get used and gradually
depleted.
2. When a chunk is freed, check if it's a neighbor to a frozen chunk,
and if so, put it at the end of its bin rather than the beginning,
so that other free chunks of the appropriate size get used first.
However this wouldn't help when it's the only chunk of its size but
another slightly-larger chunk would be a better candidate to split.
3. Allow merging directly into frozen chunks, the same way merging
into free chunks is done now, with logic to expand the region
that's PROT_NONE similar to the current logic for expanding the
MADV_DONTNEED region.
Of these, option 3 looks the most promising.
Rich
next prev parent reply other threads:[~2014-04-03 4:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-02 21:08 Rich Felker
2014-04-03 4:43 ` Rich Felker [this message]
2014-04-03 18:17 ` M. Ziebell
2014-04-03 19:17 ` 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=20140403044323.GR26358@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--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).