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.