From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by sourceware.org (Postfix) with ESMTPS id 2996538CC6A2 for ; Mon, 12 Dec 2022 03:37:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2996538CC6A2 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8FA715C009D; Sun, 11 Dec 2022 22:37:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 11 Dec 2022 22:37:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1670816228; x= 1670902628; bh=JXGK8Vyn0+9IyhApe6WBGZohXsDGKRnJpl8CMu1UOwo=; b=5 vkjLd2MMlyKfDXtAwp+M3kgn6v2ti30VU3ywRXLZN22Ro8tNpR0K2l+rmV3+jKvF jfgjXI/28ruWXrcib8ZBqsLUdXbK4S80I2KXogqETsGjT2YvVPM9PymWYwC+PSrg GVm4JY9F8blv7PylFN1Kv1mP6WZXqgdo2AVgbmnVQMIotbrs9Lya9BACXSad9n9w PESLcT+XKDMNPunJgGK2v60aEhMnIJi8vmk1IEVnfg/DLJPrT9UxD/pthAZk5Zfd QMRWBWENqCafhZD1jvUfolEz/xal1IXoLbx23V4RPiBncXVGkCtIMGwo8SRWznwR OSwNdBwG7PeZ3Lna2eGIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1670816228; x= 1670902628; bh=JXGK8Vyn0+9IyhApe6WBGZohXsDGKRnJpl8CMu1UOwo=; b=i ZAGohjFfrYiKju6uG5wMjpVMya3e1ETZjY1Zdc5vakmNAgsv+Lte3so3mj9XcHEf nModn7+W/10AFg4d7sQ7xo3eOA33p9o9sxw5AM39bkfDOUpzhv+xD0RBDHTm5SYn bCVbm4V16tid4yN51CJ+5b2rUiesm8CKKKwDqBK7X+r3GnAKT892w/c0q3xgvpUx AhXdM3vnEEu86P4z1QWMiUUE1HUfNYagiZt0MTaogQvACMxweMDegx8KDtEXUg+I f/pXiaHMJ7NHAZjWi0WMzmrUutK/T20hf+cacR204kWoAPLMhCOw3CNQJiPCfC8q Q4PzbNKe4OYZ57uo7uFog== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdejgdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvvefufhffjgfkfgggtgfgsehtqh ertddtreejnecuhfhrohhmpegkrggtkhcuhggvihhnsggvrhhguceoiigrtghksehofihl fhholhhiohdrohhrgheqnecuggftrfgrthhtvghrnhephfdvveeugfejueehgeefjeehhf ehgeekjefhjefhgfevudfhheejgffgleffgfehnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 11 Dec 2022 22:37:08 -0500 (EST) From: Zack Weinberg To: DJ Delorie Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] malloc: Use correct C11 atomics for fastbin References: Date: Sun, 11 Dec 2022 22:35:25 -0500 In-Reply-To: (DJ Delorie's message of "Tue, 06 Dec 2022 11:19:21 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: DJ Delorie writes: > Zack Weinberg via Libc-alpha writes: >> Every time we start talking about fastbins vs tcache again I start=20 >> wondering, again, what's stopping us from replacing the entire malloc=20 >> implementation with jemalloc, > > There's a couple of things, but they're technical details, not political > ones: > > * There's a copy of a "mini-malloc" in the dynamic loader that needs to > be somewhat compatible with the full copy in libc.so so that data > allocated in the loader can be used later. Hmm. Why does the dynamic loader need to be able to allocate memory at all, and how does it manage to play nice with LD_PRELOADed malloc replacements if it does this? > * The current malloc knows a lot about glibc internals like pthreads and > fork, so as to manage those boundaries properly (thread start/stop, > etc). Similarly I am wondering how _this_ manages to work with LD_PRELOADed malloc replacements. (I confess I haven=E2=80=99t ever dug into this part = of glibc much at all.) > * Benchmarks have shown that the various mallocs each have their strong > points and weak points, so expect some complaints about performance > loss when switching mallocs. Your favorite allocator may perform > poorly in someone else's favorite application. > * Testing, testing, testing. Libc's malloc is used in all Linux distros > *and* Hurd, which means it's known to work with tens if not hundreds of > thousands of programs. To propose a new system-wide allocator, you > need to replicate this level of effective testing. It seems to me that this sets the bar for _any_ major change to glibc malloc so high that it won=E2=80=99t ever happen, and given that every benc= hmark _I=E2=80=99ve_ been pointed at shows glibc malloc coming in somewhere betwe= en =E2=80=9Cmediocre=E2=80=9D and =E2=80=9Cdead last=E2=80=9D, that=E2=80=99s = a shame. zw