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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13920 invoked from network); 19 Sep 2022 20:28:54 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 20:28:54 -0000 Received: (qmail 2044 invoked by uid 550); 19 Sep 2022 20:28:51 -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 2012 invoked from network); 19 Sep 2022 20:28:51 -0000 Date: Mon, 19 Sep 2022 16:28:39 -0400 From: Rich Felker To: baiyang Cc: musl Message-ID: <20220919202838.GY9709@brightrain.aerifal.cx> References: <2022091915532777412615@gmail.com> <20220919134319.GN9709@brightrain.aerifal.cx> <202209200132289145679@gmail.com> <20220919181556.GT9709@brightrain.aerifal.cx> <2022092002445709017731@gmail.com> <20220919191820.GU9709@brightrain.aerifal.cx> <2022092003453382350548@gmail.com> <20220919200744.GW9709@brightrain.aerifal.cx> <2022092004171908873459@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2022092004171908873459@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: 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 04:17:20AM +0800, baiyang wrote: > > Clearly you did not measure this, because with basically any > > real-world malloc, it will call mremap and move the memory via > > MMU-level remapping, with no copying involved whatsoever. > > OK, I've been said multiple times: > > ...and the chance of merging chunks (small blocks) or **mremap** > > (large blocks) in the underlayer realloc. To my knowledge there is no allocator which does chunk merging on 500k chunks in the default configuration. > > ...evaluate the cost (including the possibility of realloc using > > block merging like in musl 1.1, and techniques like **mremap** to > > avoid copying) musl 1.1.x never did block merging on objects of this size. > Therefore, we determined that the possibility of each memory > allocator calling mremap in different situations was specifically > considered on the LINUX platform. > > And I mentioned it before: we did massively optimize performance in > real-world applications. These are not the focus of our discussion. > > So now it is certain that in musl mallocng: > 1. malloc_usable_size will always just return the size submitted by > the user to malloc, not the actual size allocated inside it, right? Yes. > 2. We have no plans to improve malloc_usable_size performance yet, right? In the absence of a concrete, quantitative report of how it's impacting performance, definitely no. Even if there is such a report, if the source of the problem is that you're gratuitously trying to second-guess realloc and making your program slower, rather than just calling realloc, it's not a very interesting report. malloc_usable_size is *not* a function whose use is recommended and it's only there at all because we can't remove an interface once adding it. If the problem is actually the size determination in realloc and free, and if you've *measured* that and can make a quantitative report on how it affected *real world usage* not a made-up benchmark, then that is potentially actionable. Rich