From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7379 invoked from network); 20 Sep 2022 13:58:47 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2022 13:58:47 -0000 Received: (qmail 32678 invoked by uid 550); 20 Sep 2022 13:58:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30064 invoked from network); 20 Sep 2022 13:55:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663682122; 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:references:references; bh=ZihiEShQzON2bvl/zI7Yx2/It0QE2kGZt+X8cpLX1Yo=; b=PHEz88zlXRlw/Rg8AWNO0P3Ie53/8mb1xvGmraHsyfqqQh0HCD2NzBEDMtrydo503Pf4dn 9PlFUNl4+OA8hZYZu8Ydd68YXURNdZOi9rqeG4IUAvaJHkakWfZHfOCJVpJg8bBoO2fMWv V7CVetf3znc8sAxZSxLgbFtkbPJStg4= X-MC-Unique: A_Lm-NkDOdiPK_06iu4NSw-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=ZihiEShQzON2bvl/zI7Yx2/It0QE2kGZt+X8cpLX1Yo=; b=eF47Osn1Uflu3UtLOoDO1GnvvfyNYSsY06CCrzAFpi+rblYnjMxJTi1CMXdy5X15oz 6UKmHMca2/D0ie4jo68+RhFQ3JqIhZw3VO6qJXtVVLLqwrTwE66nQSH0pcNG/ollIHlq 1IUJl97Gxwf2Wc7nRZe/W3cqlgZvsdxk8t1DCk/zVvbP1RiPv4mIca3RPm/ovGlMZMFh LLH/50gc3qt5QFjmGOHJwwmJTBnFjNTeXL2SOGTDftykCDapdXQldX9HwWojckEUW0Yp DHwkJlaeFUH1Znt0XokmxPEeOEGUgxbmXsnwCXygU1AxJiLIFf9/KeudqiJrkXPowXvT R9Tg== X-Gm-Message-State: ACrzQf0uwJB/8cGLFjcUWF7/a8gPnv4adshyCF1Ab6XGytSSAbyw9H2H Z5rxriFNIC5VJ4UElL1f5ROxeWke84RKUpd32tvUnEtNsaWPyUBel3OTbZ8x5Fgdmm/JEC8qlZC Z530mkAAp/8THrB/U25/NX5UnxeziwKqDXg== X-Received: by 2002:a17:907:6d28:b0:781:c4a3:4a08 with SMTP id sa40-20020a1709076d2800b00781c4a34a08mr2432546ejc.280.1663682119810; Tue, 20 Sep 2022 06:55:19 -0700 (PDT) X-Google-Smtp-Source: AMsMyM70Ep9daZca+jrGj/7AHF8NKrDTbX0XgRqDgvvJa2F14pYAAuiza8cZT2k3gs+LTunxGbo+lczHx9uxYCYVKZ8= X-Received: by 2002:a17:907:6d28:b0:781:c4a3:4a08 with SMTP id sa40-20020a1709076d2800b00781c4a34a08mr2432527ejc.280.1663682119528; Tue, 20 Sep 2022 06:55:19 -0700 (PDT) MIME-Version: 1.0 References: <2022091915532777412615@gmail.com> <20220919110829.GA2158779@port70.net> <874jx3h76u.fsf@oldenburg.str.redhat.com> <20220919134659.GO9709@brightrain.aerifal.cx> <874jx2phqm.fsf@oldenburg.str.redhat.com> In-Reply-To: <874jx2phqm.fsf@oldenburg.str.redhat.com> From: Siddhesh Poyarekar Date: Tue, 20 Sep 2022 09:54:43 -0400 Message-ID: To: Florian Weimer Cc: Rich Felker , baiyang , musl X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) On Tue, Sep 20, 2022 at 4:34 AM Florian Weimer wrote: > The compiler needs to treat malloc_usable_size similar to realloc and > just the size information for the buffer based on the return value from > malloc_usable_size. This is admittedly harder to do than a comparable > analysis for realloc if the compiler interprets the standard in such a > way that after a successful realloc, any access to the original pointer > value is undefined. > > malloc_usable_size is not actually *that* useful with allocators that do > not have strict size classes because they do not over-allocate that > much. For these allocators, it may be possible to increase the size of > allocation significantly without moving it, but that is not reflected in > the return value of malloc_usable_size at all. So the glibc manual does not document malloc_usable_size semantics (which is weird since it is, well, a GNU extension!) so the only reference users have is the man page. The man page already discourages use of malloc_usable_size to write beyond the allocated size in the NOTES section: The value returned by malloc_usable_size() may be greater than the requested size of the allocation because of alignment and minimum size constraints. Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice: the number of excess bytes in an allocation depends on the underlying implementation. Adding support for something that's already declared as bad programming practice seems like a step backwards. Instead, I hope we find a way to discourage active use of malloc_usable_size more strongly. At least based on the systemd experience, the problem they try to solve is that of glibc realloc being too slow for paths where the reallocation should return the same block and that should be easy to special-case. Is there any other valid reason to use malloc_usable_size instead of simply using realloc? Sid