From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14908 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Non-candidate allocator designs, things to learn from them Date: Wed, 06 Nov 2019 11:06:59 +0100 Message-ID: <87ftj1pbcs.fsf@oldenburg2.str.redhat.com> References: <20191022174051.GA24726@brightrain.aerifal.cx> <20191106034605.GB16318@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="56604"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-14924-gllmg-musl=m.gmane.org@lists.openwall.com Wed Nov 06 11:07:23 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iSIDi-000Edl-PQ for gllmg-musl@m.gmane.org; Wed, 06 Nov 2019 11:07:22 +0100 Original-Received: (qmail 22265 invoked by uid 550); 6 Nov 2019 10:07:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22240 invoked from network); 6 Nov 2019 10:07:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573034827; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7u2E6PgebiwdusyoX9icu9/Qk4F4wIO2v/fsCDWlyP0=; b=Gk1186CHLseqeO95SUottP27RER/n2rNUhR+YKKbt8duiZKgDdNVDRLb1JD0HiqLtjq9Bb qSlJZxDyLb1QMMPN61E9uj2Cl1Gk4zh5mR1GCyW4IMhJB77nDOevQVAWZKnMkBSlGlWVjI psc1QeZQ4vrmRym6Zbq64eBG+OLQDss= In-Reply-To: <20191106034605.GB16318@brightrain.aerifal.cx> (Rich Felker's message of "Tue, 5 Nov 2019 22:46:05 -0500") X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: 7447RaS1PfCke-zf-sp3Jg-1 X-Mimecast-Spam-Score: 0 Xref: news.gmane.org gmane.linux.lib.musl.general:14908 Archived-At: * 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