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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_FONT_FACE_BAD,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2,T_KAM_HTML_FONT_INVALID autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22293 invoked from network); 20 Sep 2022 20:46:12 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2022 20:46:12 -0000 Received: (qmail 30296 invoked by uid 550); 20 Sep 2022 20:46:09 -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 30273 invoked from network); 20 Sep 2022 20:46:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:mime-version:references:subject:cc:to:from:date:from:to :cc:subject:date; bh=3gSYC83Cd82wyZehcI21xe8OIUcVdj4B9TbpcQSKKow=; b=QDbWdJRgaprAQfyLmciUuBHaAwW4QORg9tnfPDQik02YsWdsqmczUNnbsmzQ4gTreV 2hZ1jNE04OU0cAmM6/xaxjDnsr5Lcq4H9zvej1fc///TolnO1DZ5bhGQMW1n3QzzrL4h CfHq2ZFyLAaHX/KJUJf7gx9ur/nsHp3Vn9hXgR5sXy/fvIosJKTozE/iG6RmAKgCilp9 zAF/bPWl7eUcb9BQ8x/tAX+TOCM2EtDMb+nPbWBMoLP4rRAdq6reRLz8SspHKFAky8n7 Gak3Ebfhq4qJ8Drr8My5N4ZYDtRFq73CzMHxgUIYgWs+YqMmKOyELqXnp6mclJmn9cTC RpbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=message-id:mime-version:references:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=3gSYC83Cd82wyZehcI21xe8OIUcVdj4B9TbpcQSKKow=; b=RICiJaj0RLdgeP2llOIwKjsVD94T1sb/nX49HCzuKw6W0cqzVviTzZ25sCzA1WryBW f/1AkeUjBWrZg6JolNnjiaDqvfT8693kIelPHMx48begVgQAZ0EPIURE6yh3eDCmeSQd PbAWB1CZXeEkx1fs7zWdaZpo+vDgRMKCYFY8KEs3RJ1AYksNXG5HjFmNKrCyl5QOFAut HDy7P/5JnRt3CM8Jdh4ZF8cDHin7VBYLZqszmC8nddlF9dKmNIErc5suKmiOMYBYZI1F q/pMdQWMm1agjizIN7dAFkqYHzgXmNGPl5oyzynTCCOWdb2gm4WPZW/w2koSUNvUtxPV khbg== X-Gm-Message-State: ACrzQf2hQIBT5zQppWNm4pgCJZJymJZEoG4JS1tQQ2MAdxGeNAZn/SwO CtC/Xk0LDqnGI0AA3/nBK1A= X-Google-Smtp-Source: AMsMyM5zjE7GB1OLLk1MvGPWSTx6x8Bs/yx8s0YlMhKREYVOSjtV6TOvjGj0D6cjvWtR3+pZ9S8aJw== X-Received: by 2002:a17:90b:1e47:b0:200:b9b4:ba0f with SMTP id pi7-20020a17090b1e4700b00200b9b4ba0fmr5759168pjb.245.1663706756730; Tue, 20 Sep 2022 13:45:56 -0700 (PDT) Date: Wed, 21 Sep 2022 04:45:59 +0800 From: baiyang To: "Gabriel Ravier" , musl Cc: "Quentin Rameau" , "Florian Weimer" 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>, , <2022092102351588157126@gmail.com>, X-Priority: 3 X-GUID: C91BA756-DE88-4FC6-9B05-9B6A35F4A70D X-Has-Attach: no X-Mailer: Foxmail 7.2.23.116[cn] Mime-Version: 1.0 Message-ID: <2022092104455700962839@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart186653657740_=----" Subject: Re: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1) This is a multi-part message in MIME format. ------=_001_NextPart186653657740_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PiBBdCB0aGlzIHBvaW50IGl0IGZlZWxzIG1vcmUgYW5kIG1vcmUgbGlrZSBtYWxsb2MgYmFzaWNh bGx5IGNhbid0IGZ1bGZpbGwgeW91ciBuZWVkcyB1bmxlc3MgZXZlcnkgaW1wbGVtZW50YXRpb24g b3V0IHRoZXJlIHN0YXJ0cyBhZGRpbmcgc3BlY2lhbGl6ZWQgbWV0aG9kcyBmb3IgeW91ciBhcHBs aWNhdGlvbi4gSW4gb3RoZXIgd29yZHMsIGl0IG1pZ2h0IGJlIG1vcmUgcHJvZHVjdGl2ZSBmb3Ig eW91IHRvIHNpbXBseSBicmluZyBpbiBhIG1vcmUgYWdyZWVhYmxlIGFsbG9jYXRvciwgaW5zdGVh ZCBvZiB0cnlpbmcgdG8gZ2V0IGV2ZXJ5IHNpbmdsZSBhbGxvY2F0b3Igb3V0IHRoZXJlIHRvIGJv dyBkb3duIHRvIHlvdXIgbmVlZHMuDQoNClllcywgd2Ugd2lsbCBhZGFwdCBhcyBtYW55IGFsbG9j YXRvcnMgYXMgcG9zc2libGUgdG8gbWFrZSBvdXIgc29mdHdhcmUgbW9yZSBwb3J0YWJsZSBhbmQg YWRhcHRhYmxlLg0KDQpGcmFua2x5LCBzbyBmYXIsIHdlJ3ZlIG9ubHkgZW5jb3VudGVyZWQgbWFs bG9jX3VzYWJsZV9zaXplIHBlcmZvcm1hbmNlIGlzc3VlcyB3aXRoIG11c2wncyBtYWxsb2NuZyAo YW5kLCBhcyB3ZSBkaXNjdXNzZWQgZWFybGllciwgdGhpcyBwZXJmb3JtYW5jZSBpc3N1ZSBhZmZl Y3RzIGJvdGggcmVhbGxvYyBhbmQgZnJlZSkuIA0KDQpPZiBjb3Vyc2UsIHdlIGFsc28gcmVzcGVj dCBhbmQgdW5kZXJzdGFuZCB0aGUgYXV0aG9yJ3MgY29uc2lkZXJhdGlvbnMgYW5kIHRyYWRlLW9m ZnMsIGFuZCBoYXZlIGF2b2lkZWQgY2FsbGluZyBtYWxsb2NfdXNhYmxlX3NpemUgZm9yIG11c2wn cyBtYWxsb2NuZyBpbiBvdXIgc29mdHdhcmUuDQoNClRoYW5rcyA6LSkNCiANCi0tDQoNCiAgIEJl c3QgUmVnYXJkcw0KICBCYWlZYW5nDQogIGJhaXlhbmdAZ21haWwuY29tDQogIGh0dHA6Ly9pLmJh aXkuY24NCioqKiogPCBFTkQgT0YgRU1BSUwgPiAqKioqIA0KIA0KIA0KRnJvbTogR2FicmllbCBS YXZpZXINCkRhdGU6IDIwMjItMDktMjEgMDQ6MzMNClRvOiBtdXNsOyBiYWl5YW5nDQpDQzogUXVl bnRpbiBSYW1lYXU7IEZsb3JpYW4gV2VpbWVyDQpTdWJqZWN0OiBSZTogW211c2xdIFRoZSBoZWFw IG1lbW9yeSBwZXJmb3JtYW5jZSAobWFsbG9jL2ZyZWUvcmVhbGxvYykgaXMgc2lnbmlmaWNhbnRs eSBkZWdyYWRlZCBpbiBtdXNsIDEuMiAoY29tcGFyZWQgdG8gMS4xKQ0KT24gOS8yMC8yMiAyMDoz NSwgYmFpeWFuZyB3cm90ZToNCj4gU28gd2hhdCB5b3UncmUgYWN0dWFsbHkgdHJ5aW5nIHRvIGRv IGlzIG1vcmUgY2xlYXIgbm93Lg0KPiBBbmQgdGhpcyBpcyBzb21ldGhpbmcgdGhhdCB5b3Ugc2hv dWxkIGRvIG9uIHRoZSDigJxhcHBsaWNhdGlvbiBsYXllcuKAnSwNCj4gbm90IGV4cGVjdCB0aGUg bGliYyB0byBtYWdpY2FsbHkgdGFraW5nIGNhcmUgb2YgdGhpcy4NCg0KWWVzLCB3ZSBqdXN0IGRv IHRoaXMgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIHdpdGggdGhlIGhlbHAgb2YgQVBJcyBzdWNo IGFzIG1hbGxvY191c2FibGVfc2l6ZS4gWW91IGNhbiBsb29rIGF0IHRoZSBwcmV2aW91cyBlbWFp bHMsIGlzbid0IHRoYXQgd2hhdCB3ZSdyZSBkaXNjdXNzaW5nPw0KDQo+IFRoZXkgd2FudCB0byBr bm93IGlmIHJlYWxsb2Mgd2lsbCByZXNpemUgdGhlIGFsbG9jYXRpb24gaW4tcGxhY2Ugc28NCj4g dGhlIGludGVybmFsIG1lbWNweSB3aWxsIG5vdCBoYXBwZW4uDQo+IEFJVUksIHdoYXQgdGhleSBy ZWFsbHkgbmVlZCBpcyBub3QgInVzYWJsZV9zaXplIiwgYnV0ICJjb3N0IGVzdGltYXRpb24NCj4g Zm9yIHJlc2l6aW5nIGFsbG9jYXRpb24gYXQgcG9pbnRlciBQIHRvIHNpemUgUyIuIFdoaWNoIEkg YmVsaWV2ZSB0aGV5DQo+IHRyeSB0byBkZWR1Y2UgZnJvbSBtYWxsb2NfdXNhYmxlX3NpemUuIA0K DQpZZXMsIGZyb20gbWFsbG9jX3VzYWJsZV9zaXplLCB0aGUgc2l6ZSB0aGF0IHRoZSBhcHBsaWNh dGlvbiBsYXllciBhY3R1YWxseSBuZWVkcyB0byBjb3B5LCBhbmQgb3RoZXIgcGFyYW1ldGVycyBs aWtlIHRoZSBPUywgYWxsb2NhdG9yLCBldGMuIA0KDQpBdCB0aGlzIHBvaW50IGl0IGZlZWxzIG1v cmUgYW5kIG1vcmUgbGlrZSBtYWxsb2MgYmFzaWNhbGx5IGNhbid0IGZ1bGZpbGwgeW91ciBuZWVk cyB1bmxlc3MgZXZlcnkgaW1wbGVtZW50YXRpb24gb3V0IHRoZXJlIHN0YXJ0cyBhZGRpbmcgc3Bl Y2lhbGl6ZWQgbWV0aG9kcyBmb3IgeW91ciBhcHBsaWNhdGlvbi4gSW4gb3RoZXIgd29yZHMsIGl0 IG1pZ2h0IGJlIG1vcmUgcHJvZHVjdGl2ZSBmb3IgeW91IHRvIHNpbXBseSBicmluZyBpbiBhIG1v cmUgYWdyZWVhYmxlIGFsbG9jYXRvciwgaW5zdGVhZCBvZiB0cnlpbmcgdG8gZ2V0IGV2ZXJ5IHNp bmdsZSBhbGxvY2F0b3Igb3V0IHRoZXJlIHRvIGJvdyBkb3duIHRvIHlvdXIgbmVlZHMuDQo= ------=_001_NextPart186653657740_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = =0A =0A =0A
> A<= /font>t this point it fee= ls more and more like malloc basically can't fulfill your needs unless eve= ry implementation out there starts adding specialized methods for your app= lication. In other words, it might be more productive for you to simply br= ing in a more agreeable allocator, instead of trying to get every single a= llocator out there to bow down to your needs.

Yes, we will adapt as many= allocators as possible to make our software more portable and adaptable.<= /div>

Frankly, so far, we've only= encountered malloc_usable_size performance issues with musl's mallocng (a= nd, as we discussed earlier, this performance issue affects both realloc a= nd free). 

Of course, = we also respect and understand the author's considerations and trade-offs,= and have avoided calling malloc_usable_size for musl's mallocng in our so= ftware.

Thanks :-)
=0A=
 
=0A
--

<= /td>		   Best Regards
  B= aiYang
  baiyang@gmail.c= om
  http://i.baiy.cn
**** < END = OF EMAIL > **** 
 
 
Date: 2022-09-21 04:33
Subject: Re: [musl] The heap memory pe= rformance (malloc/free/realloc) is significantly degraded in musl 1.2 (com= pared to 1.1)
=0A =0A =0A =0A =0A
On 9/20/22= 20:35, baiyang wrote:
=0A
=0A
=0A =0A =0A
=0A =
> So what you're actually trying to do is more clear=0A = now.
=0A
> And this is something that you should = do on the=0A =E2=80=9Capplication layer=E2=80=9D,
=0A =
> not expect the libc to magically taking care of this.
=0A =
=0A

=0A
=0A
Yes, we just do = this at the application layer with the help=0A of APIs such as mall= oc_usable_size. You can look at the previous=0A emails, isn't that = what we're discussing?
=0A

=0A
=0A > They want to know if realloc will resize the=0A al= location in-place so
=0A
> the internal memcpy wi= ll not happen.
=0A
> AIUI, what they really need is not = "usable_size", but=0A "cost estimation
=0A
> for = resizing allocation at pointer P to size S". Which I=0A believe the= y
=0A
> try to deduce from ma= lloc_usable_size. 
=0A

=0A
=0A
<= span style=3D"background-color: transparent;">Yes, from malloc_usable_size, the size that the=0A = application layer actually needs to copy, and other=0A par= ameters like the OS, allocator, etc. 
=0A
=0A = =0A

At this point it feels more and more like= =0A malloc basically can't fulfill your needs unless every=0A im= plementation out there starts adding specialized methods for=0A your = application. In other words, it might be more productive for=0A you t= o simply bring in a more agreeable allocator, instead of=0A trying to= get every single allocator out there to bow down to your=0A needs.=0A

=0A =0A
=0A ------=_001_NextPart186653657740_=------