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 11765 invoked from network); 19 Sep 2022 11:08:48 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 11:08:48 -0000 Received: (qmail 3340 invoked by uid 550); 19 Sep 2022 11:08:44 -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 3300 invoked from network); 19 Sep 2022 11:08:43 -0000 Date: Mon, 19 Sep 2022 13:08:29 +0200 From: Szabolcs Nagy To: baiyang Cc: musl Message-ID: <20220919110829.GA2158779@port70.net> Mail-Followup-To: baiyang , musl References: <2022091915532777412615@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2022091915532777412615@gmail.com> Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) * baiyang [2022-09-19 15:53:30 +0800]: > Hi there, > > As we have discussed at https://github.com/openwrt/openwrt/issues/10752. The malloc_usable_size() function in musl 1.2 (mallocng) seems to have some performance issues. > > It caused realloc and free spends too long time for get the chunk size. how is malloc_usable_size related to free and realloc performance? > > As we mentioned in the discussion, tcmalloc and some other allocators can also accurately obtain the size class corresponding to a memory block and its precise size, and it is also very fast at the same time. unlike musl those implementations don't return exact size nor have the same security and memory fragmentation guarantees, so bad comparision. tcmalloc: // Returns the actual number N of bytes reserved by tcmalloc for the pointer // p. This number may be equal to or greater than the number of bytes // requested when p was allocated. // // This function is just useful for statistics collection. The client must // *not* read or write from the extra bytes that are indicated by this call. jemalloc: The malloc_usable_size() function returns the usable size of the allocation pointed to by ptr. The return value may be larger than the size that was requested during allocation. The malloc_usable_size() function is not a mechanism for in-place realloc(); rather it is provided solely as a tool for introspection purposes. Any discrepancy between the requested allocation size and the size reported by malloc_usable_size() should not be depended on, since such behavior is entirely implementation-dependent. > > Can we make some improvements to the existing malloc_usable_size algorithm in mallocng? This should significantly improve the performance of existing algorithms. can you give an actual interesting workload where that's the bottleneck? given that calling this function is almost always a bug in production code, it's hard to see how it can cause performance problems.