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 7695 invoked from network); 20 Sep 2022 18:38:09 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2022 18:38:09 -0000 Received: (qmail 7681 invoked by uid 550); 20 Sep 2022 18:38:07 -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 7654 invoked from network); 20 Sep 2022 18:38:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fifth.space; s=20190812; t=1663699074; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WSgHgEGNt+XPOJ4bXYIqmFijzyREq0JxnqPS0bheBzI=; b=pAl8eq6d8/PDyI1dt9U6j2hTHTgS8b8nD1jDJYkdT+Gi4C8ueMT3OzhDlVMvueYW5xfSaf 6Gju/+RSxjUDffKvfP83vzEyUKgYub3bHpWDUp3p7yWrKg9acm3wvQMrKNtqTS8ENCp+Le AvpNcZbhKhqaeIdxklhFmz6U2nXfb3vAZcfjuPpEal4bLqnahA3EcmV2Ow8BdjWrau7rdl /thUVL6230N+ZCyOnVBlzUH47U81QxI2swfK7cfeeApLDBxuLs1P99D1kkNqqF1ruLCyRa UqMWCl7A3zkcxz0qCDOpSGV14Qve+AKgaZ9dnbUCvfcUcHaRtAd4wQA3I8gWdA== Date: Tue, 20 Sep 2022 20:37:53 +0200 From: Quentin Rameau To: musl@lists.openwall.com Message-ID: <20220920203753.50b9b94e.quinq@fifth.space> In-Reply-To: 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> <2022092101393822582117@gmail.com> <20220920201244.4f40362e.quinq@fifth.space> <20220920181905.GR9709@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) Hi Alexander, > > Exactly. This can be done entirely at the application layer just by > > keeping track of the size you allocated. In the above example, the > > number 256 kB is a red herring. Yes the > > "malloc(300KB)+memcpy(256KB)+free(256KB)" is wasteful, but the > > "malloc(300KB)+memcpy(200KB)+free(200KB)" would be comparably wasteful > > when you only want to preserve the first 2K, and you can make the > > decision that it would be wasteful, and that you instead just want to > > allocate a new buffer yourself and memcpy 2K, just by knowing the > > original 200KB, without any knowledge of malloc_usable_size. > > They want to know if realloc will resize the allocation in-place so > the internal memcpy will not happen. > > AIUI, what they really need is not "usable_size", but "cost estimation > for resizing allocation at pointer P to size S". Which I believe they > try to deduce from malloc_usable_size. I see. But then I doubt this is something you can reliably expect from any implementation, as at best, one would just have to assume that the target allocator works in one way and wouldn't change. This will result in a code tightly bound to a specific alocator because of the assumptions made about the library internals. This is not really the kind of contract one makes with the POSIX/C library in a portable way. So if the request really is to press every libc implementation into adopting one user's (or a few) self-made requirements, that still doesn't sound like a constructive conversation here. At this point if ones really needs micro-management of their memory, they should just implement their own allocator.