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 12717 invoked from network); 19 Sep 2022 20:17:33 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 20:17:33 -0000 Received: (qmail 27757 invoked by uid 550); 19 Sep 2022 20:17:30 -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 27718 invoked from network); 19 Sep 2022 20:17:29 -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=qC16mDEVklKwtVE1V/SrVVW6lXaFrfxj0RWOIOATVYM=; b=YVxw78jT79QCUs6mz51qirf2MbAuy1sVuOp0ZYc03ONdZWbl+ELGFQ/xCYcI4KXCw4 aNrTDCHbjkVWAfS9csUSgVE51QkJjrMkCmOYZJR03OGHSCaAHRS5oNFsc3CZ/TZ9CoVe q9jGHpaZpDQ1fmaxNZl3qJcMX7A9AUMUcv/snXuk3ELCCsKQ0b3mf3ZSIKuePR3xn5Z0 nggQXMCzSvaO/09WsXCPb4YGUJFcCkGnZ5sve+9D8le0auzwVIfAHKL8kXayHZ+oMKeB oyKpEzOfjnzapkh/5jLf7qqelnkAF+5yalFcKJqoomODL9WVCxgLaWd9cIwHHma9ti9X pBKA== 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=qC16mDEVklKwtVE1V/SrVVW6lXaFrfxj0RWOIOATVYM=; b=6KC1EcsPiCZk//4/228XAl/86Ld325jh47nMOZ1yuIbLdzvIyKzk3Kgnfi+Bl+rbMB JwwPoWyeHzA+RVAaetAO7ENHdNNsyg62l8mBbC8x0f57LMimIwkfUYXMBSb9d3BdrEp1 tQqsSLm/DlgBIGKMyMW87guZBGHm/t0buyOsAnYitElFcehKCvTZ+nlsNQwgfFFXcYdM EFzOyFie7wj29wy4ulJ9q6oQPFpfMCXuvbtJ7clKK2iHag9jS46319OPuzZVu+GnpvHY wES/KQG67fMU1uYa+LMjlrr5BpB/+fYFsgfzRXYEjOOGUdJdzV3sLg6i5uUIm1NLdRQP BCKA== X-Gm-Message-State: ACrzQf1dNBmgoFWRtpPqz7bcDKQ97hJ9+HmVnGuEfhfFrsjBeVLVBxs2 TzI+onjD41MsF5qe6ubrASA= X-Google-Smtp-Source: AMsMyM7ZdhCgzm0rYZbOwljH35X1k/mRlp7SEzjrVL/rSfbkAEAh9A0DqIJGglkUO8ic/9BIzLwIHw== X-Received: by 2002:a17:902:e80b:b0:176:de36:f5a8 with SMTP id u11-20020a170902e80b00b00176de36f5a8mr1408303plg.127.1663618637546; Mon, 19 Sep 2022 13:17:17 -0700 (PDT) Date: Tue, 20 Sep 2022 04:17:20 +0800 From: baiyang To: "Rich Felker" Cc: musl 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> X-Priority: 3 X-GUID: 6CD16365-3D9C-4A25-94F6-CC1831FA8615 X-Has-Attach: no X-Mailer: Foxmail 7.2.23.116[cn] Mime-Version: 1.0 Message-ID: <2022092004171908873459@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart850146178400_=----" 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_NextPart850146178400_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBDbGVhcmx5IHlvdSBkaWQgbm90IG1lYXN1cmUgdGhpcywgYmVjYXVzZSB3aXRoIGJhc2ljYWxs eSBhbnkgcmVhbC13b3JsZCBtYWxsb2MsIGl0IHdpbGwgY2FsbCBtcmVtYXAgYW5kIG1vdmUgdGhl IG1lbW9yeSB2aWEgTU1VLWxldmVsIHJlbWFwcGluZywgd2l0aCBubyBjb3B5aW5nIGludm9sdmVk IHdoYXRzb2V2ZXIuIA0KDQpPSywgSSd2ZSBiZWVuIHNhaWQgbXVsdGlwbGUgdGltZXM6IA0KPiAu Li5hbmQgdGhlIGNoYW5jZSBvZiBtZXJnaW5nIGNodW5rcyAoc21hbGwgYmxvY2tzKSBvciAqKm1y ZW1hcCoqIChsYXJnZSBibG9ja3MpIGluIHRoZSB1bmRlcmxheWVyIHJlYWxsb2MuDQo+IC4uLmV2 YWx1YXRlIHRoZSBjb3N0IChpbmNsdWRpbmcgdGhlIHBvc3NpYmlsaXR5IG9mIHJlYWxsb2MgdXNp bmcgYmxvY2sgbWVyZ2luZyBsaWtlIGluIG11c2wgMS4xLCBhbmQgdGVjaG5pcXVlcyBsaWtlICoq bXJlbWFwKiogdG8gYXZvaWQgY29weWluZykNCg0KVGhlcmVmb3JlLCB3ZSBkZXRlcm1pbmVkIHRo YXQgdGhlIHBvc3NpYmlsaXR5IG9mIGVhY2ggbWVtb3J5IGFsbG9jYXRvciBjYWxsaW5nIG1yZW1h cCBpbiBkaWZmZXJlbnQgc2l0dWF0aW9ucyB3YXMgc3BlY2lmaWNhbGx5IGNvbnNpZGVyZWQgb24g dGhlIExJTlVYIHBsYXRmb3JtLg0KDQpBbmQgSSBtZW50aW9uZWQgaXQgYmVmb3JlOiB3ZSBkaWQg bWFzc2l2ZWx5IG9wdGltaXplIHBlcmZvcm1hbmNlIGluIHJlYWwtd29ybGQgYXBwbGljYXRpb25z LiBUaGVzZSBhcmUgbm90IHRoZSBmb2N1cyBvZiBvdXIgZGlzY3Vzc2lvbi4NCg0KU28gbm93IGl0 IGlzIGNlcnRhaW4gdGhhdCBpbiBtdXNsIG1hbGxvY25nOg0KMS4gbWFsbG9jX3VzYWJsZV9zaXpl IHdpbGwgYWx3YXlzIGp1c3QgcmV0dXJuIHRoZSBzaXplIHN1Ym1pdHRlZCBieSB0aGUgdXNlciB0 byBtYWxsb2MsIG5vdCB0aGUgYWN0dWFsIHNpemUgYWxsb2NhdGVkIGluc2lkZSBpdCwgcmlnaHQ/ DQoyLiBXZSBoYXZlIG5vIHBsYW5zIHRvIGltcHJvdmUgbWFsbG9jX3VzYWJsZV9zaXplIHBlcmZv cm1hbmNlIHlldCwgcmlnaHQ/DQoNCnRoYW5rcw0KDQotLQ0KDQogICBCZXN0IFJlZ2FyZHMNCiAg QmFpWWFuZw0KICBiYWl5YW5nQGdtYWlsLmNvbQ0KICBodHRwOi8vaS5iYWl5LmNuDQoqKioqIDwg RU5EIE9GIEVNQUlMID4gKioqKiANCiANCiANCkZyb206IFJpY2ggRmVsa2VyDQpEYXRlOiAyMDIy LTA5LTIwIDA0OjA3DQpUbzogYmFpeWFuZw0KQ0M6IG11c2wNClN1YmplY3Q6IFJlOiBSZTogW211 c2xdIFRoZSBoZWFwIG1lbW9yeSBwZXJmb3JtYW5jZSAobWFsbG9jL2ZyZWUvcmVhbGxvYykgaXMg c2lnbmlmaWNhbnRseSBkZWdyYWRlZCBpbiBtdXNsIDEuMiAoY29tcGFyZWQgdG8gMS4xKQ0KT24g VHVlLCBTZXAgMjAsIDIwMjIgYXQgMDM6NDU6MzVBTSArMDgwMCwgYmFpeWFuZyB3cm90ZToNCj4g PiBUaGUgb25seSBjb3JyZWN0IHZhbHVlIG1hbGxvY191c2FibGVfc2l6ZSBjYW4gcmV0dXJuIGlz IHRoZSB2YWx1ZQ0KPiA+IHlvdSBwYXNzZWQgdG8gdGhlIGFsbG9jYXRvci4NCj4gDQo+IEkgZG9u J3QgdGhpbmsgc28sIHNlZToNCj4gDQo+IExpbnV4IG1hbiBwYWdlOg0KPiBodHRwczovL21hbjcu b3JnL2xpbnV4L21hbi1wYWdlcy9tYW4zL21hbGxvY191c2FibGVfc2l6ZS4zLmh0bWwgLQ0KPiAi VGhlIHZhbHVlIHJldHVybmVkIGJ5IG1hbGxvY191c2FibGVfc2l6ZSgpIG1heSBiZSAqKmdyZWF0 ZXIgdGhhbioqDQo+IHRoZSByZXF1ZXN0ZWQgc2l6ZSBvZiB0aGUgYWxsb2NhdGlvbiIuDQo+IA0K PiBNYWMgT1MgWCBtYW4gcGFnZToNCj4gaHR0cHM6Ly9kZXZlbG9wZXIuYXBwbGUuY29tL2xpYnJh cnkvYXJjaGl2ZS9kb2N1bWVudGF0aW9uL1N5c3RlbS9Db25jZXB0dWFsL01hblBhZ2VzX2lQaG9u ZU9TL21hbjMvbWFsbG9jX3NpemUuMy5odG1sDQo+IC0gIlRoZSBtZW1vcnkgYmxvY2sgc2l6ZSBp cyBhbHdheXMgYXQgbGVhc3QgYXMgbGFyZ2UgYXMgdGhlDQo+IGFsbG9jYXRpb24gaXQgYmFja3Ms ICoqYW5kIG1heSBiZSBsYXJnZXIqKi4iDQo+IA0KPiBGcmVlQlNEIG1hbiBwYWdlOg0KPiBodHRw czovL3d3dy5mcmVlYnNkLm9yZy9jZ2kvbWFuLmNnaT9xdWVyeT1tYWxsb2NfdXNhYmxlX3NpemUm YXByb3Bvcz0wJnNla3Rpb249MCZtYW5wYXRoPUZyZWVCU0QrNy4xLVJFTEVBU0UmZm9ybWF0PWh0 bWwNCj4gLSAiVGhlIHJldHVybiB2YWx1ZSAqKm1heSBiZSBsYXJnZXIqKiB0aGFuIHRoZSBzaXpl IHRoYXQgd2FzDQo+IHJlcXVlc3RlZCBkdXJpbmcgYWxsb2NhdGlvbiIuDQo+IA0KPiBUaGVzZSBv ZmZpY2lhbCBtYW4gcGFnZXMgY2xlYXJseSBzdGF0ZSB0aGF0IHRoZSByZXR1cm4gdmFsdWUgb2YN Cj4gbWFsbG9jX3VzYWJsZV9zaXplIGlzIHRoZSBzaXplIG9mIHRoZSBtZW1vcnkgYmxvY2sgYWxs b2NhdGVkDQo+IGludGVybmFsbHksIG5vdCB0aGUgc2l6ZSBzdWJtaXR0ZWQgYnkgdGhlIHVzZXIu DQo+IA0KPiBJbnN0ZWFkLCB3ZSBkaWRuJ3QgZmluZCBhbnkgZG9jdW1lbnRhdGlvbiBzYXlpbmcg dGhhdCB0aGUgcmV0dXJuDQo+IHZhbHVlIG9mIG1hbGxvY191c2FibGVfc2l6ZSBtdXN0IGJlIHRo ZSBzaXplIHN1Ym1pdHRlZCBieSB0aGUgdXNlcg0KPiB0byBiZSBjb3JyZWN0LiBQbGVhc2UgY29y cmVjdCBtZSBpZiB5b3UgaGF2ZSB0aGUgcmVsZXZhbnQNCj4gZG9jdW1lbnRhdGlvbi4NCiANCk9L LCBJIGRpZG4ndCBzdGF0ZSB0aGF0IHByZWNpc2VseS4gVGhlcmUgYXJlIHR3byBjb25mbGljdGlu ZyBjbGFpbXMNCmZvciB3aGF0IHRoZSBtYWxsb2NfdXNhYmxlX3NpemUgY29udHJhY3QgaXMuIElm IGl0J3MgYWxsb3dlZCB0byByZXR1cm4NCnNvbWUgdmFsdWUgbGFyZ2VyIHRoYW4gdGhlIHNpemUg eW91IHJlcXVlc3RlZCwgdGhlbiB0aGUgc2l6ZSByZXR1cm5lZA0KaXMgbm90IGFjdHVhbGx5ICJ1 c2FibGUiIGFuZCB0aGVyZSdzIGJhc2ljYWxseSBub3RoaW5nIHVzZWZ1bCB5b3UgY2FuDQpkbyB3 aXRoIHRoZSBmdW5jdGlvbi4NCiANCj4gPiBJdCdzIHNvdW5kaW5nIG1vcmUgYW5kIG1vcmUgbGlr ZSB5b3UgZGlkIHByZW1hdHVyZSBvcHRpbWl6YXRpb24NCj4gPiB3aXRob3V0IG1lYXN1cmluZyBh bnkgb2YgdGhpcywgc2luY2UgdGhlcmUgaXMgKm5vIHdheSogdGhlIHBvc3NpYmxlDQo+ID4gYW1v dW50IG9mIGV4Y2VzcyBjb3B5aW5nIGEgcmVhbGxvYyBpbXBsZW1lbnRhdGlvbiBtaWdodCBtYWtl DQo+ID4gaW50ZXJuYWxseSBjb3VsZCBjb3N0IG1vcmUgdGhhbiBhbiBleHRyYSBleHRlcm5hbCBm dW5jdGlvbiBjYWxsIHRvDQo+ID4gbWFsbG9jX3VzYWJsZV9zaXplIChldmVuIGlmIGl0IGRpZCBu b3RoaW5nIGJ1dCByZXR1cm4pLg0KPiANCj4gQXMgSSBzYWlkIGJlZm9yZToNCj4gPiBXZSBoYXZl IGEgcmVhbCBzY2VuYXJpbyB3aGVyZSBgbWFsbG9jX3VzYWJsZV9zaXplYCBpcyBjYWxsZWQNCj4g PiBmcmVxdWVudGx5OiB3ZSBuZWVkIHRvIG9wdGltaXplIHRoZSByZWFsbG9jIGV4cGVyaWVuY2Uu IFdlIGFkZCBhbg0KPiA+IGV4dHJhIHBhcmFtZXRlciB0byByZWFsbG9jIC0gbWluaW1hbENvcHlC eXRlczogaXQgcmVwcmVzZW50cyB0aGUNCj4gPiBhY3R1YWwgc2l6ZSBvZiBkYXRhIHRoYXQgbmVl ZHMgdG8gYmUgY29waWVkIGFmdGVyIGZhbGxiYWNrIHRvDQo+ID4gbWFsbG9jLWNvcHktZnJlZSBt b2RlLiBXZSB3aWxsIGp1ZGdlIHdoZXRoZXIgdG8gY2FsbCByZWFsbG9jIG9yDQo+ID4gY29tcGxl dGUgbWFsbG9jLW1lbWNweS1mcmVlIGJ5IG91cnNlbGYgYmFzZWQgb24gZmFjdG9ycyBzdWNoIGFz DQo+ID4gdGhlIHNpemUgb2YgdGhlIGRhdGEgdGhhdCByZWFsbG9jIG5lZWRzIHRvIGNvcHkgKG9i dGFpbmVkIHRocm91Z2gNCj4gPiBgbWFsbG9jX3VzYWJsZV9zaXplYCksIHRoZSBzaXplIHRoYXQg d2UgYWN0dWFsbHkgbmVlZCB0byBjb3B5IHdoZW4NCj4gPiB3ZSBkb2luZyBtYWxsb2MtbWVtY3B5 LWZyZWUgb3Vyc2VsZiAobWluaW1hbENvcHlCeXRlcykgYW5kIHRoZQ0KPiA+IGNoYW5jZSBvZiBt ZXJnaW5nIGNodW5rcyAoc21hbGwgYmxvY2tzKSBvciBtcmVtYXAgKGxhcmdlIGJsb2NrcykNCj4g PiBpbiB0aGUgdW5kZXJsYXllciByZWFsbG9jLiBTbywgdGhpcyBpcyBhIHJlYWwgc2NlbmFyaW8s IHdlIG5lZWQgdG8NCj4gPiBjYWxsIGBtYWxsb2NfdXNhYmxlX3NpemVgIGZyZXF1ZW50bHkuDQo+ IA0KPiBFeGFtcGxlOiBXZSBhbGxvY2F0ZSBhIGJsb2NrIG9mIDUwMEtCIChtYWxsb2MgYWN0dWFs bHkgYWxsb2NhdGVkDQo+IDUxMktCKSBhbmQgd2FudCB0byBleHRlbmQgaXQgdG8gNTc2S0Igdmlh IHJlYWxsb2MuIEF0IHRoaXMgcG9pbnQNCj4gcmVhbGxvYyBtYXkgZG93bmdyYWRlIGJhY2sgdG8g dGhlIGluZWZmaWNpZW50IG1hbGxvYyg3NTZLQiksDQo+IG1lbWNweSg1MTJLQikgYW5kIGZyZWUo NTEyS0IpIG1vZGVzLg0KIA0KQ2xlYXJseSB5b3UgZGlkIG5vdCBtZWFzdXJlIHRoaXMsIGJlY2F1 c2Ugd2l0aCBiYXNpY2FsbHkgYW55DQpyZWFsLXdvcmxkIG1hbGxvYywgaXQgd2lsbCBjYWxsIG1y ZW1hcCBhbmQgbW92ZSB0aGUgbWVtb3J5IHZpYQ0KTU1VLWxldmVsIHJlbWFwcGluZywgd2l0aCBu byBjb3B5aW5nIGludm9sdmVkIHdoYXRzb2V2ZXIuDQogDQo+IEJ1dCB0aGUgcmVhbCBzaXR1YXRp b24gYXQgdGhpcw0KPiB0aW1lIG1heSBiZSB0aGF0IHdlIG9ubHkgbmVlZCB0byBrZWVwIHRoZSBm aXJzdCA0S0Igb2YgY29udGVudCBpbg0KPiA1MDBLQiwgc28gd2UgY29tcHJlaGVuc2l2ZWx5IGV2 YWx1YXRlIHRoZSBjb3N0IChpbmNsdWRpbmcgdGhlDQo+IHBvc3NpYmlsaXR5IG9mIHJlYWxsb2Mg dXNpbmcgYmxvY2sgbWVyZ2luZyBsaWtlIGluIG11c2wgMS4xLCBhbmQNCj4gdGVjaG5pcXVlcyBs aWtlIG1yZW1hcCB0byBhdm9pZCBjb3B5aW5nKSB0byBkZWNpZGUgd2hldGhlciB0bw0KPiBjb21w bGV0ZSBtYWxsb2MoNTc2S0IpLCBtZW1jcHkoKio0S0IqKiksIGZyZWUoNTEyS0IpIGJ5IG91cnNl bHZlcw0KPiBhcmUgbW9yZSBjb3N0LWVmZmVjdGl2ZS4NCiANCllvdSBjb3VsZCBoYXZlIGFjaGll dmVkIGV4YWN0bHkgdGhlIHNhbWUgdGhpbmcgYnkga2VlcGluZyB5b3VyIG93bg0Ka25vd2xlZGdl IHRoYXQgeW91IGFsbG9jYXRlZCA1MDBrQi4gQnV0IGl0IHdvdWxkIHN0aWxsIGJlDQpzaWduaWZp Y2FudGx5IHNsb3dlciwgYmVjYXVzZSBtbWFwK21lbWNweSttdW5tYXAgKDIgc3lzY2FsbHMpIGlz DQpzbG93ZXIgdGhhbiBtcmVtYXAgKDEgc3lzY2FsbCkuDQogDQo+IFN1Y2ggb3B0aW1pemF0aW9u cyBoYXZlIG1lYXN1cmFibGUgYW5kIHNpZ25pZmljYW50IGVmZmVjdHMgb24gb3VyDQo+IHByYWN0 aWNhbCBhcHBsaWNhdGlvbnMgaW4gZWFjaCBvZiB0aGUgYWJvdmUgbGliYyBlbnZpcm9ubWVudHMu DQo+IA0KPiBJbiB0aGlzIHNjZW5hcmlvLCB3ZSBuZWVkIHRvIGdldCB0aGUgNTEyS0IgYWN0dWFs bHkgYWxsb2NhdGVkIGJ5DQo+IG1hbGxvYyB0aHJvdWdoIG1hbGxvY191c2FibGVfc2l6ZSBpbnN0 ZWFkIG9mIHRoZSA1MDBLQiBsZW5ndGggd2UNCj4gc2F2ZWQgb3Vyc2VsdmVzLg0KIA0KTm8geW91 IGRvbid0LiBFaXRoZXIgbnVtYmVyIHdvcmtzIGp1c3QgYXMgd2VsbCAob3IgcmF0aGVyIGp1c3Qg YXMNCnBvb3JseSkuDQogDQpSaWNoDQo= ------=_001_NextPart850146178400_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
> Clearly you did not measure th= is, because with basically any MMU-level remapping, with no copying i= nvolved whatsoever. 

OK, I've been said multiple times: 
> ...and= the chance of merging chunks (small = blocks) or **mremap** (large blocks) = in the underlayer realloc.
> ...evaluate the cost = (including the possibility of realloc= using block merging like in musl 1.1, and=  techniques like **mremap** to avoid copying)
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 di= d massively optimize performance in real-world applications. These are not the focus of our di= scussion.

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?
= 2. We have no plans to improve malloc_usable_size performance yet, right?<= /div>
=0A

tha= nks

=0A
--
   Best Regards
&n= bsp; BaiYang
  baiyang@g= mail.com
  http://i.baiy.cn<= /a>
**** <= ; END OF EMAIL > **** 
 
 
Fro= m: Rich Felker
<= b>Date: 2022-09-20 04:07
To: baiyang
CC: musl
Subject:&nb= sp;Re: Re: [musl] The heap memory performance (malloc/free/realloc) is sig= nificantly degraded in musl 1.2 (compared to 1.1)
On Tue, Sep 20, 2022 at 03:45:35AM +0800, baiyang wrote:
=0A
&= gt; > The only correct value malloc_usable_size can return is the value=
=0A
> > you passed to the allocator.
=0A
> =0A
> I don't think so, see:
=0A
>
=0A
>= ; Linux man page:
=0A
> https://man7.org/linux/man-pages/man3/= malloc_usable_size.3.html -
=0A
> "The value returned by mallo= c_usable_size() may be **greater than**
=0A
> the requested si= ze of the allocation".
=0A
>
=0A
> Mac OS X man p= age:
=0A
> https://developer.apple.com/library/archive/documen= tation/System/Conceptual/ManPages_iPhoneOS/man3/malloc_size.3.html
= =0A
> - "The memory block size is always at least as large as the=0A
> allocation it backs, **and may be larger**."
=0A>
=0A
> FreeBSD man page:
=0A
> https://www.f= reebsd.org/cgi/man.cgi?query=3Dmalloc_usable_size&apropos=3D0&sekt= ion=3D0&manpath=3DFreeBSD+7.1-RELEASE&format=3Dhtml
=0A
&= gt; - "The return value **may be larger** than the size that was
=0A<= div>> requested during allocation".
=0A
>
=0A
>= ; These official man pages clearly state that the return value of
=0A=
> malloc_usable_size is the size of the memory block allocated=0A
> internally, not the size submitted by the user.
=0A>
=0A
> Instead, we didn't find any documentation saying= that the return
=0A
> value of malloc_usable_size must be the= size submitted by the user
=0A
> to be correct. Please correc= t me if you have the relevant
=0A
> documentation.
=0A 
=0A
OK, I didn't state that precisely. There are two con= flicting claims
=0A
for what the malloc_usable_size contract is. = If it's allowed to return
=0A
some value larger than the size you= requested, then the size returned
=0A
is not actually "usable" a= nd there's basically nothing useful you can
=0A
do with the funct= ion.
=0A
 
=0A
> > It's sounding more and mor= e like you did premature optimization
=0A
> > without measu= ring any of this, since there is *no way* the possible
=0A
> &= gt; amount of excess copying a realloc implementation might make
=0A<= div>> > internally could cost more than an extra external function c= all to=0A
> > malloc_usable_size (even if it did nothing b= ut return).
=0A
>
=0A
> As I said before:
= =0A
> > We have a real scenario where `malloc_usable_size` is ca= lled
=0A
> > frequently: we need to optimize the realloc ex= perience. We add an
=0A
> > extra parameter to realloc - mi= nimalCopyBytes: it represents the
=0A
> > actual size of da= ta that needs to be copied after fallback to
=0A
> > malloc= -copy-free mode. We will judge whether to call realloc or
=0A
>= ; > complete malloc-memcpy-free by ourself based on factors such as=0A
> > the size of the data that realloc needs to copy (obtai= ned through
=0A
> > `malloc_usable_size`), the size that we= actually need to copy when
=0A
> > we doing malloc-memcpy-= free ourself (minimalCopyBytes) and the
=0A
> > chance of m= erging chunks (small blocks) or mremap (large blocks)
=0A
> &g= t; in the underlayer realloc. So, this is a real scenario, we need to=0A
> > call `malloc_usable_size` frequently.
=0A
>=
=0A
> Example: We allocate a block of 500KB (malloc actually= allocated
=0A
> 512KB) and want to extend it to 576KB via rea= lloc. At this point
=0A
> realloc may downgrade back to the in= efficient malloc(756KB),
=0A
> memcpy(512KB) and free(512KB) m= odes.
=0A
 
=0A
Clearly you did not measure this, b= ecause with basically any
=0A
real-world malloc, it will call mre= map and move the memory via
=0A
MMU-level remapping, with no copy= ing involved whatsoever.
=0A
 
=0A
> But the rea= l situation at this
=0A
> time may be that we only need to kee= p the first 4KB of content in
=0A
> 500KB, so we comprehensive= ly evaluate the cost (including the
=0A
> possibility of reall= oc using block merging like in musl 1.1, and
=0A
> techniques = like mremap to avoid copying) to decide whether to
=0A
> compl= ete malloc(576KB), memcpy(**4KB**), free(512KB) by ourselves
=0A
= > are more cost-effective.
=0A
 
=0A
You could h= ave achieved exactly the same thing by keeping your own
=0A
knowl= edge that you allocated 500kB. But it would still be
=0A
signific= antly slower, because mmap+memcpy+munmap (2 syscalls) is
=0A
slow= er than mremap (1 syscall).
=0A
 
=0A
> Such opt= imizations have measurable and significant effects on our
=0A
>= ; practical applications in each of the above libc environments.
=0A<= div>>
=0A
> In this scenario, we need to get the 512KB act= ually allocated by
=0A
> malloc through malloc_usable_size ins= tead of the 500KB length we
=0A
> saved ourselves.
=0A 
=0A
No you don't. Either number works just as well (or r= ather just as
=0A
poorly).
=0A
 
=0A
Rich<= /div>=0A
=0A ------=_001_NextPart850146178400_=------