From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: "e@80x24.org" <e@80x24.org>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>
Subject: [RFT] malloc: reduce largebin granularity to reduce fragmentation
Date: Fri, 12 Apr 2024 15:19:12 +0000 [thread overview]
Message-ID: <PAWPR08MB89827CD885891415D2A6051183042@PAWPR08MB8982.eurprd08.prod.outlook.com> (raw)
Hi Eric,
I agree that limiting size classes will help with fragmentation. However
you need more than this: when it finds a block that is larger than requested
it will always split off the end even if it is a much smaller block. As a result
large blocks get smaller over time. Additionally allocations that can't be
satisfied by the free lists are taken from the large remainder of the arena,
thus interleaving allocations of all sizes rather than grouping similar sizes
together in separate regions like modern allocators.
The tcache and smallbin freelist also keeps freed block listed as 'allocated',
thus blocking merging of free blocks into larger ones - this is only done
every now and again during a consolidation pass. Threads that free blocks
but never allocate a large block again may never really free their freed
blocks.
So to reduce fragmentation you also have to address all these issues too.
My general feeling is that this allocator is way too ancient and hacked up to
compete with modern allocators like jemalloc or mimalloc.
Cheers,
Wilco
next reply other threads:[~2024-04-12 15:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 15:19 Wilco Dijkstra [this message]
2024-04-12 15:35 ` [RFT] malloc: reduce largebin granularity to reduce fragmentation Cristian Rodríguez
2024-04-12 17:02 ` Eric Wong
[not found] <CAPBLoAfHRKGRjFQFKHXwK6vX7xxUqkoj?= =?ISO-8859-1?Q?-=5Fsttmfn4FgiEgondA@mail.gmail.com>
2024-04-12 21:50 ` DJ Delorie
-- strict thread matches above, loose matches on Subject: below --
2024-04-09 9:33 Eric Wong
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
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=PAWPR08MB89827CD885891415D2A6051183042@PAWPR08MB8982.eurprd08.prod.outlook.com \
--to=wilco.dijkstra@arm.com \
--cc=e@80x24.org \
--cc=libc-alpha@sourceware.org \
/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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).