Date: Tue, 20 Sep 2022 04:38:08 +0800 From: baiyang <baiyang@...il.com> To: "Rich Felker" <dalias@...c.org> Cc: musl <musl@...ts.openwall.com> Subject: Re: Re: The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) > To my knowledge there is no allocator which does chunk merging on 500k chunks in the default configuration. It can be ANY size, "500KB" is just an example. > musl 1.1.x never did block merging on objects of this size. Yes, we known it, and we will evaluate according to the specific situation of the operating system, libc implementation and allocation size. Again, this is not the point of this discussion. > In the absence of a concrete, quantitative report of how it's impacting performance, definitely no. OK, I understood and thanks for your time. -- Best Regards BaiYang baiyang@...il.com http://i.baiy.cn **** < END OF EMAIL > **** From: Rich Felker Date: 2022-09-20 04:28 To: baiyang CC: musl 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 Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.