From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 0807738469BF for ; Tue, 6 Dec 2022 16:19:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0807738469BF Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670343573; 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: in-reply-to:in-reply-to; bh=YcLryXZK73waJbeXVBeoEN5ZpOsKBS5bItj5bG8hMFQ=; b=TbsGF3aeU4hmeVhx709MfRtF9QRY0nq5AQa0YEOz8MmEtahnWCzCVfO9/DWJWADwjweFUR ZGzOMvbBTzwl1adphhsojSilcU56H9mt+Ixn207CXTRQS/s/bf+T/yzhqML6Uew4SafB/m IXwLgRTTCE4MSdCv2lJ/cZGrAOb6nQI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-671-r89yMvf2ONiHSEcYFKlcUQ-1; Tue, 06 Dec 2022 11:19:32 -0500 X-MC-Unique: r89yMvf2ONiHSEcYFKlcUQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 451F985A5A6; Tue, 6 Dec 2022 16:19:32 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.8.183]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 31965C15BA4; Tue, 6 Dec 2022 16:19:32 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.15.2/8.15.2) with ESMTP id 2B6GJLsH1816425; Tue, 6 Dec 2022 11:19:21 -0500 From: DJ Delorie To: Zack Weinberg Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] malloc: Use correct C11 atomics for fastbin In-Reply-To: Date: Tue, 06 Dec 2022 11:19:21 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: Zack Weinberg via Libc-alpha writes: > Every time we start talking about fastbins vs tcache again I start > wondering, again, what's stopping us from replacing the entire malloc > 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. * The current malloc knows a lot about glibc internals like pthreads and fork, so as to manage those boundaries properly (thread start/stop, etc). * 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. > or any other implementation designed less than 20 years ago. Comments like this are not appreciated. Age does not imply quality. Please stick to technical points.