[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ftj1pbcs.fsf@oldenburg2.str.redhat.com>
Date: Wed, 06 Nov 2019 11:06:59 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Non-candidate allocator designs, things to learn from them
* Rich Felker:
> Aside from that, this kind of design also suffers from extreme
> over-allocation in small programs, and it's not compatible with nommu
> at all (since it relies on the mmu to cheat fragmentation). For
> example, if you allocate just one object of each of 50 sizes classes,
> you'll be using at least 50 pages (200k) already.
I've recently seen an announcement of a malloc which uses alias mappings
to encode the size class in the address. This way, you would only need
to start out with one or two pages in userspace. But the page table
overhead in the kernel (which is missing from your calculation) is still
there because I don't think the kernel can share the page tables for the
alias mappings.
Another concern with such allocators is the increased TLB pressure and
page walking overhead.
Thanks,
Florian
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.
