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_FONT_LOW_CONTRAST, 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 8966 invoked from network); 19 Sep 2022 19:45:49 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Sep 2022 19:45:49 -0000 Received: (qmail 9546 invoked by uid 550); 19 Sep 2022 19:45:46 -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 9510 invoked from network); 19 Sep 2022 19:45:45 -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=Iv1C9LTeZg5xQjao/m1m8PTU7GWYeAJ4m+NydwGTFf8=; b=SGNL2EL8qlDBo85pN+z4ERJJnIlFWgAzPbOU9xN8K56YP1W2tsbqq6AGxDaOftgGY3 zUQSIcwNcPqjWLIQXghJT5Hmnjtwi1I4oq+HKK8LZmjHnLyPzgY9ViPrYKIBXEPGSU0b b7GgEsuCelPiRLnDC2j2UM9Ml2q4PxQPv0l+giWyByQnLpQjAFxKOE0HbnMjuy5Dv2qc S9l0V8uEh2GmUJaTIBximWJPzEZe6T51MOQ1oLBZUhYm/QuNQoRRFCSOaWbRnq+Rougd icKA8pqdPB3iyv++Y+NtXBLQ08J0GUYi59WA1eOjGg3tua1yOonNIjnwqYOZFQ6UDyfW jbEw== 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=Iv1C9LTeZg5xQjao/m1m8PTU7GWYeAJ4m+NydwGTFf8=; b=qdGTSOQDAp5AsrqEEnWpUVIw92Oaz+6qCgZmJGLg0wySsjw/ftmAszKgxIFlcFY+F+ ckC+btQkN5xGSS5810eY5UQC3MvQB/0kfmWq6vF48gX94yjTRjVnqlqOMQDShMHfC+I8 vNnFkvk2e7rdzcC1999icQtO/TGtCxLTX9YbKQtd06OQJqVRhW5Jvpz5mo0CaTHVHQ/a A4u8AWA+tWFrYjZfacbUeiRHaXqK+9uy1VpGVgOLTULeJ5cH3qJdXSZYJZZwHleovE7K Qsi0XrEX2QW72Px+WzIGUV+4K3jxoGNkS4GQB31Br5SBJYHbsLboLLRTCDPMQ1nEMyei V8lQ== X-Gm-Message-State: ACrzQf10wjQJ9xR6rloDMthDsSmbv4/k7pkNQKWlizig5fHE+kQZtYUD waHUuhRPPpkJfWd/em0tNbs= X-Google-Smtp-Source: AMsMyM6cfUU33e1mH+7E/WXa/rDA4chDFcMJplz7tf3qsvRHY20YBr7OwI6p9tVvuG9I/6Vv9maxWQ== X-Received: by 2002:a05:6a00:854:b0:542:4254:17f6 with SMTP id q20-20020a056a00085400b00542425417f6mr19860510pfk.47.1663616732802; Mon, 19 Sep 2022 12:45:32 -0700 (PDT) Date: Tue, 20 Sep 2022 03:45:35 +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> X-Priority: 3 X-GUID: E8F84964-4A54-4C99-B87B-6BA03413ED01 X-Has-Attach: no X-Mailer: Foxmail 7.2.23.116[cn] Mime-Version: 1.0 Message-ID: <2022092003453382350548@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart457751300562_=----" 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_NextPart457751300562_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGUgb25seSBjb3JyZWN0IHZhbHVlIG1hbGxvY191c2FibGVfc2l6ZSBjYW4gcmV0dXJuIGlz IHRoZSB2YWx1ZSB5b3UgcGFzc2VkIHRvIHRoZSBhbGxvY2F0b3IuIA0KDQpJIGRvbid0IHRoaW5r IHNvLCBzZWU6DQoNCkxpbnV4IG1hbiBwYWdlOiBodHRwczovL21hbjcub3JnL2xpbnV4L21hbi1w YWdlcy9tYW4zL21hbGxvY191c2FibGVfc2l6ZS4zLmh0bWwgLSAiVGhlIHZhbHVlIHJldHVybmVk IGJ5IG1hbGxvY191c2FibGVfc2l6ZSgpIG1heSBiZSAqKmdyZWF0ZXIgdGhhbioqIHRoZSByZXF1 ZXN0ZWQgc2l6ZSBvZiB0aGUgYWxsb2NhdGlvbiIuDQoNCk1hYyBPUyBYIG1hbiBwYWdlOiBodHRw czovL2RldmVsb3Blci5hcHBsZS5jb20vbGlicmFyeS9hcmNoaXZlL2RvY3VtZW50YXRpb24vU3lz dGVtL0NvbmNlcHR1YWwvTWFuUGFnZXNfaVBob25lT1MvbWFuMy9tYWxsb2Nfc2l6ZS4zLmh0bWwg LSAiVGhlIG1lbW9yeSBibG9jayBzaXplIGlzIGFsd2F5cyBhdCBsZWFzdCBhcyBsYXJnZSBhcyB0 aGUgYWxsb2NhdGlvbiBpdCBiYWNrcywgKiphbmQgbWF5IGJlIGxhcmdlcioqLiINCg0KRnJlZUJT RCBtYW4gcGFnZTogaHR0cHM6Ly93d3cuZnJlZWJzZC5vcmcvY2dpL21hbi5jZ2k/cXVlcnk9bWFs bG9jX3VzYWJsZV9zaXplJmFwcm9wb3M9MCZzZWt0aW9uPTAmbWFucGF0aD1GcmVlQlNEKzcuMS1S RUxFQVNFJmZvcm1hdD1odG1sIC0gIlRoZSByZXR1cm4gdmFsdWUgKiptYXkgYmUgbGFyZ2VyKiog dGhhbiB0aGUgc2l6ZSB0aGF0IHdhcyByZXF1ZXN0ZWQgZHVyaW5nIGFsbG9jYXRpb24iLg0KDQpU aGVzZSBvZmZpY2lhbCBtYW4gcGFnZXMgY2xlYXJseSBzdGF0ZSB0aGF0IHRoZSByZXR1cm4gdmFs dWUgb2YgbWFsbG9jX3VzYWJsZV9zaXplIGlzIHRoZSBzaXplIG9mIHRoZSBtZW1vcnkgYmxvY2sg YWxsb2NhdGVkIGludGVybmFsbHksIG5vdCB0aGUgc2l6ZSBzdWJtaXR0ZWQgYnkgdGhlIHVzZXIu IA0KDQpJbnN0ZWFkLCB3ZSBkaWRuJ3QgZmluZCBhbnkgZG9jdW1lbnRhdGlvbiBzYXlpbmcgdGhh dCB0aGUgcmV0dXJuIHZhbHVlIG9mIG1hbGxvY191c2FibGVfc2l6ZSBtdXN0IGJlIHRoZSBzaXpl IHN1Ym1pdHRlZCBieSB0aGUgdXNlciB0byBiZSBjb3JyZWN0LiBQbGVhc2UgY29ycmVjdCBtZSBp ZiB5b3UgaGF2ZSB0aGUgcmVsZXZhbnQgZG9jdW1lbnRhdGlvbi4NCg0KPiBJdCdzIHNvdW5kaW5n IG1vcmUgYW5kIG1vcmUgbGlrZSB5b3UgZGlkIHByZW1hdHVyZSBvcHRpbWl6YXRpb24NCj4gd2l0 aG91dCBtZWFzdXJpbmcgYW55IG9mIHRoaXMsIHNpbmNlIHRoZXJlIGlzICpubyB3YXkqIHRoZSBw b3NzaWJsZQ0KPiBhbW91bnQgb2YgZXhjZXNzIGNvcHlpbmcgYSByZWFsbG9jIGltcGxlbWVudGF0 aW9uIG1pZ2h0IG1ha2UNCj4gaW50ZXJuYWxseSBjb3VsZCBjb3N0IG1vcmUgdGhhbiBhbiBleHRy YSBleHRlcm5hbCBmdW5jdGlvbiBjYWxsIHRvDQo+IG1hbGxvY191c2FibGVfc2l6ZSAoZXZlbiBp ZiBpdCBkaWQgbm90aGluZyBidXQgcmV0dXJuKS4NCg0KQXMgSSBzYWlkIGJlZm9yZToNCj4gV2Ug aGF2ZSBhIHJlYWwgc2NlbmFyaW8gd2hlcmUgYG1hbGxvY191c2FibGVfc2l6ZWAgaXMgY2FsbGVk IGZyZXF1ZW50bHk6IHdlIG5lZWQgdG8gb3B0aW1pemUgdGhlIHJlYWxsb2MgZXhwZXJpZW5jZS4g V2UgYWRkIGFuIGV4dHJhIHBhcmFtZXRlciB0byByZWFsbG9jIC0gbWluaW1hbENvcHlCeXRlczog aXQgcmVwcmVzZW50cyB0aGUgYWN0dWFsIHNpemUgb2YgZGF0YSB0aGF0IG5lZWRzIHRvIGJlIGNv cGllZCBhZnRlciBmYWxsYmFjayB0byBtYWxsb2MtY29weS1mcmVlIG1vZGUuIFdlIHdpbGwganVk Z2Ugd2hldGhlciB0byBjYWxsIHJlYWxsb2Mgb3IgY29tcGxldGUgbWFsbG9jLW1lbWNweS1mcmVl IGJ5IG91cnNlbGYgYmFzZWQgb24gZmFjdG9ycyBzdWNoIGFzIHRoZSBzaXplIG9mIHRoZSBkYXRh IHRoYXQgcmVhbGxvYyBuZWVkcyB0byBjb3B5IChvYnRhaW5lZCB0aHJvdWdoIGBtYWxsb2NfdXNh YmxlX3NpemVgKSwgdGhlIHNpemUgdGhhdCB3ZSBhY3R1YWxseSBuZWVkIHRvIGNvcHkgd2hlbiB3 ZSBkb2luZyBtYWxsb2MtbWVtY3B5LWZyZWUgb3Vyc2VsZiAobWluaW1hbENvcHlCeXRlcykgYW5k IHRoZSBjaGFuY2Ugb2YgbWVyZ2luZyBjaHVua3MgKHNtYWxsIGJsb2Nrcykgb3IgbXJlbWFwIChs YXJnZSBibG9ja3MpIGluIHRoZSB1bmRlcmxheWVyIHJlYWxsb2MuIFNvLCB0aGlzIGlzIGEgcmVh bCBzY2VuYXJpbywgd2UgbmVlZCB0byBjYWxsIGBtYWxsb2NfdXNhYmxlX3NpemVgIGZyZXF1ZW50 bHkuDQoNCkV4YW1wbGU6IFdlIGFsbG9jYXRlIGEgYmxvY2sgb2YgNTAwS0IgKG1hbGxvYyBhY3R1 YWxseSBhbGxvY2F0ZWQgNTEyS0IpIGFuZCB3YW50IHRvIGV4dGVuZCBpdCB0byA1NzZLQiB2aWEg cmVhbGxvYy4gQXQgdGhpcyBwb2ludCByZWFsbG9jIG1heSBkb3duZ3JhZGUgYmFjayB0byB0aGUg aW5lZmZpY2llbnQgbWFsbG9jKDc1NktCKSwgbWVtY3B5KDUxMktCKSBhbmQgZnJlZSg1MTJLQikg bW9kZXMuIEJ1dCB0aGUgcmVhbCBzaXR1YXRpb24gYXQgdGhpcyB0aW1lIG1heSBiZSB0aGF0IHdl IG9ubHkgbmVlZCB0byBrZWVwIHRoZSBmaXJzdCA0S0Igb2YgY29udGVudCBpbiA1MDBLQiwgc28g d2UgY29tcHJlaGVuc2l2ZWx5IGV2YWx1YXRlIHRoZSBjb3N0IChpbmNsdWRpbmcgdGhlIHBvc3Np YmlsaXR5IG9mIHJlYWxsb2MgdXNpbmcgYmxvY2sgbWVyZ2luZyBsaWtlIGluIG11c2wgMS4xLCBh bmQgdGVjaG5pcXVlcyBsaWtlIG1yZW1hcCB0byBhdm9pZCBjb3B5aW5nKSB0byBkZWNpZGUgd2hl dGhlciB0byBjb21wbGV0ZSBtYWxsb2MoNTc2S0IpLCBtZW1jcHkoKio0S0IqKiksIGZyZWUoNTEy S0IpIGJ5IG91cnNlbHZlcyBhcmUgbW9yZSBjb3N0LWVmZmVjdGl2ZS4NCg0KU3VjaCBvcHRpbWl6 YXRpb25zIGhhdmUgbWVhc3VyYWJsZSBhbmQgc2lnbmlmaWNhbnQgZWZmZWN0cyBvbiBvdXIgcHJh Y3RpY2FsIGFwcGxpY2F0aW9ucyBpbiBlYWNoIG9mIHRoZSBhYm92ZSBsaWJjIGVudmlyb25tZW50 cy4NCg0KSW4gdGhpcyBzY2VuYXJpbywgd2UgbmVlZCB0byBnZXQgdGhlIDUxMktCIGFjdHVhbGx5 IGFsbG9jYXRlZCBieSBtYWxsb2MgdGhyb3VnaCBtYWxsb2NfdXNhYmxlX3NpemUgaW5zdGVhZCBv ZiB0aGUgNTAwS0IgbGVuZ3RoIHdlIHNhdmVkIG91cnNlbHZlcy4NCg0KVGhhbmtzIDotKQ0KDQot LQ0KDQogICBCZXN0IFJlZ2FyZHMNCiAgQmFpWWFuZw0KICBiYWl5YW5nQGdtYWlsLmNvbQ0KICBo dHRwOi8vaS5iYWl5LmNuDQoqKioqIDwgRU5EIE9GIEVNQUlMID4gKioqKiANCiANCiANCkZyb206 IFJpY2ggRmVsa2VyDQpEYXRlOiAyMDIyLTA5LTIwIDAzOjE4DQpUbzogYmFpeWFuZw0KQ0M6IG11 c2wNClN1YmplY3Q6IFJlOiBSZTogW211c2xdIFRoZSBoZWFwIG1lbW9yeSBwZXJmb3JtYW5jZSAo bWFsbG9jL2ZyZWUvcmVhbGxvYykgaXMgc2lnbmlmaWNhbnRseSBkZWdyYWRlZCBpbiBtdXNsIDEu MiAoY29tcGFyZWQgdG8gMS4xKQ0KT24gVHVlLCBTZXAgMjAsIDIwMjIgYXQgMDI6NDQ6NThBTSAr MDgwMCwgYmFpeWFuZyB3cm90ZToNCj4gPiBJcyB0aGVyZSBhIHJlYXNvbiB5b3UncmUgcmVseWlu ZyBvbiBhbiB1bnJlbGlhYmxlIGFuZCBub25zdGFuZGFyZA0KPiA+IGZ1bmN0aW9uIChtYWxsb2Nf dXNhYmxlX3NpemUpIHRvIGRvIHRoaXMgcmF0aGVyIHRoYW4geW91ciBwcm9ncmFtDQo+ID4ga2Vl cGluZyB0cmFjayBvZiBpdHMgb3duIGtub3dsZWRnZSBvZiB0aGUgYWxsb2NhdGVkIHNpemU/IFRo aXMgaXMgd2hhdA0KPiA+IHRoZSBDIGxhbmd1YWdlIGV4cGVjdHMgeW91IHRvIGRvLiBGb3IgZXhh bXBsZSBpZiB5b3UgaGF2ZSBhIHN0cnVjdHVyZQ0KPiA+IHRoYXQgY29udGFpbnMgYSBwb2ludGVy IHRvIGEgZHluYW1pY2FsbHkgc2l6ZWQgYnVmZmVyLCBub3JtYWxseSB5b3UNCj4gPiBzdG9yZSB0 aGUgc2l6ZSBpbiBhIHNpemVfdCBtZW1iZXIgcmlnaHQgbmV4dCB0byB0aGF0IHBvaW50ZXIsIGFs bG93aW5nDQo+ID4geW91IHRvIG1ha2UgdGhlc2Uga2luZCBvZiBkZWNpc2lvbnMgd2l0aG91dCBo YXZpbmcgdG8gcHJvYmUgYW55dGhpbmcuDQo+IA0KPiBZZXMsIGFzIEkgaGF2ZSBiZWVuIHNhaWQs IGJ5IGNvbXBhcmluZyB0aGUgbnVtYmVyIG9mIGJ5dGVzIHRoYXQNCj4gcmVhbGxvYyBuZWVkcyB0 byBjb3B5IGluIHRoZSB3b3JzdCBjYXNlICh0aGUgcmV0dXJuIHZhbHVlIG9mDQo+IG1hbGxvY191 c2FibGVfc2l6ZSksIGFuZCB0aGUgbnVtYmVyIG9mIGJ5dGVzIHdlIGFjdHVhbGx5IG5lZWQgdG8N Cj4gY29weSwgd2UgY2FuIG9wdGltaXplIHRoZSBwZXJmb3JtYW5jZSBvZiByZWFsbG9jIGluIHJl YWwgc2NlbmFyaW9zDQo+IGFuZCBhdm9pZCB1bm5lY2Vzc2FyeSBtZW1vcnkgY29waWVzLg0KIA0K WW91IGNhbiBkbyBleGFjdGx5IHRoZSBzYW1lIGtlZXBpbmcgdHJhY2sgb2YgdGhlIHNpemUgeW91 cnNlbGYuIFRoZQ0Kb25seSBjb3JyZWN0IHZhbHVlIG1hbGxvY191c2FibGVfc2l6ZSBjYW4gcmV0 dXJuIGlzIHRoZSB2YWx1ZSB5b3UNCnBhc3NlZCB0byB0aGUgYWxsb2NhdG9yLiBJZiBpdCdzIHJl dHVybmluZyBhIGRpZmZlcmVudCBzaXplLCB5b3VyDQptYWxsb2MgaW1wbGVtZW50YXRpb24gaGFz IGEgcHJvYmxlbSB0aGF0IHdpbGwgbWFrZSB5b3UgY29tbWl0IFVCIHdoZW4NCnlvdSB1c2UgdGhl IHJlc3VsdCBvZiBtYWxsb2NfdXNhYmxlX3NpemUuIE1hbnkgcmVhbC13b3JsZCBvbmVzIGRvIGhh dmUNCnRoaXMgcHJvYmxlbS4NCiANCj4gSW4gZmFjdCwgaW4gc2NlbmFyaW9zIGluY2x1ZGluZyBn bGliYywgdGNtYWxsb2MsIHdpbmRvd3MgY3J0LCBtYWMgb3MNCj4geCwgdWNsaWJjIGFuZCBtdXNs IDEuMSwgd2UgZGlkIGFjaGlldmUgZ29vZCBvcHRpbWl6YXRpb24gcmVzdWx0cy4NCj4gDQo+IE9u IHRoZSBvdGhlciBoYW5kLCBvZiBjb3Vyc2Ugd2Uga2VlcCB0aGUgbnVtYmVyIG9mIGJ5dGVzIGFj dHVhbGx5DQo+IGFsbG9jYXRlZCwgYnV0IGl0IGRvZXNuJ3QgcmVhbGx5IHJlZmxlY3Qgb2JqZWN0 aXZlbHkgdGhlIG51bWJlciBvZg0KPiBieXRlcyB0byBiZSBjb3BpZWQgYnkgcmVhbGxvYyB3aGVu IHRoZSBtZW1jcHkgYWN0dWFsbHkgb2NjdXJzLiBBbmQNCj4gbWFsbG9jX3VzYWJsZV9zaXplKCkg bW9yZSBhY2N1cmF0ZWx5IHJlZmxlY3RzIGhvdyBtYW55IGJ5dGVzIHJlYWxsb2MNCj4gbmVlZHMg dG8gY29weSB3aGVuIGl0IGRlZ2VuZXJhdGVzIGJhY2sgdG8gbWFsbG9jLW1lbWNweS1mcmVlIG1v ZGUuDQogDQpJIGRvbid0IHVuZGVyc3RhbmQgeW91ciBjbGFpbSBoZXJlLiBUaGUgc2l6ZSB5b3Ug d291bGQgc3RvcmUgaXMNCmV4YWN0bHkgdGhlIHNpemUgdGhhdCByZWFsbG9jIHdvdWxkIGhhdmUg dG8gY29weS4gSXQgaWYgY29waWVzIG1vcmUsDQp0aGF0J3MganVzdCByZWFsbG9jIGJlaW5nIGlu ZWZmaWNpZW50LCBidXQgdGhlIGRpZmZlcmVuY2UgaXMgbm90IGdvaW5nDQp0byBiZSBtYXRlcmlh bCBhbnl3YXkuDQogDQo+IFNvIG91ciBleHBlY3RhdGlvbiBpcyBhcyBtZW50aW9uZWQgaW4gdGhl IG1hbiBwYWdlIGZvciBsaW51eCwgbWFjIG9zDQo+IG9yIHdpbmRvd3M6ICJUaGUgdmFsdWUgcmV0 dXJuZWQgYnkgbWFsbG9jX3VzYWJsZV9zaXplKCkgbWF5IGJlDQo+ICoqZ3JlYXRlciB0aGFuKiog dGhlIHJlcXVlc3RlZCBzaXplIG9mIHRoZSBhbGxvY2F0aW9uIiBvciAiVGhlDQo+IG1lbW9yeSBi bG9jayBzaXplIGlzIGFsd2F5cyBhdCBsZWFzdCBhcyBsYXJnZSBhcyB0aGUgYWxsb2NhdGlvbiBp dA0KPiBiYWNrcywgKiphbmQgbWF5IGJlIGxhcmdlcioqLiIgLSBXZSBleHBlY3QgdG8gZ2V0IGl0 cyBpbnRlcm5hbCBzaXplDQo+IHRvIGV2YWx1YXRlIHRoZSBjb3N0IG9mIG1lbW9yeSBjb3B5aW5n Lg0KIA0KSXQncyBzb3VuZGluZyBtb3JlIGFuZCBtb3JlIGxpa2UgeW91IGRpZCBwcmVtYXR1cmUg b3B0aW1pemF0aW9uDQp3aXRob3V0IG1lYXN1cmluZyBhbnkgb2YgdGhpcywgc2luY2UgdGhlcmUg aXMgKm5vIHdheSogdGhlIHBvc3NpYmxlDQphbW91bnQgb2YgZXhjZXNzIGNvcHlpbmcgYSByZWFs bG9jIGltcGxlbWVudGF0aW9uIG1pZ2h0IG1ha2UNCmludGVybmFsbHkgY291bGQgY29zdCBtb3Jl IHRoYW4gYW4gZXh0cmEgZXh0ZXJuYWwgZnVuY3Rpb24gY2FsbCB0bw0KbWFsbG9jX3VzYWJsZV9z aXplIChldmVuIGlmIGl0IGRpZCBub3RoaW5nIGJ1dCByZXR1cm4pLg0KIA0KUmljaA0K ------=_001_NextPart457751300562_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
> The&nbs= p;only c= orrect value malloc_usable_size can return is the value you passed to = the allocator. =0A

I don't think so, see:=

Linux man page: = ;https://man7.org/linux/man-pages/man3/malloc_usable_size.3.html - "The value retu= rned by malloc_usable_size() may be **greater than** the requested siz= e of the allocation".

Mac OS X man page: = https://developer.apple.com/library/archive/documentation/System/Conceptua= l/ManPages_iPhoneOS/man3/malloc_size.3.html - "The memory block size is always&n= bsp;at least as large as the allocation it backs, **and may be larger**."

FreeBSD man page: <= /font>https://www.freebsd.or= g/cgi/man.cgi?query=3Dmalloc_usable_size&apropos=3D0&sektion=3D0&a= mp;manpath=3DFreeBSD+7.1-RELEASE&format=3Dhtml - "Th= e return value **may be larger** than the size that w= as requested du= ring allocation".

These official man pages clearly state that = the return value of malloc_usable_size is the size of the memory block all= ocated internally, not the size submitted by the user. 
<= div style=3D"">
Instead, we di= dn't find any documentation saying that the return value of malloc_usable_= size must be the size submitted by the user to be correct. Please correct me if you have the relevant documentation.

<= div style=3D"">> It's sounding more and mo= re like you did premature optimization
> without measu= ring any of this, since there is *no way* the possible
> amou= nt of excess copying a realloc implementation might make
> in= ternally could cost more than an extra external function call to
> malloc_usable_size (even if it did nothing but return).
As I said before:
> We have a real scenario where `malloc_usable_size` is called frequen= tly: we need to optimize the realloc experience. We add an extra parameter to realloc - minimalCopy= Bytes: it represents the actual size of data that needs to be copied after= fallback to malloc-copy-free mode. We will judge whether to call realloc or complete malloc-memcpy= -free by ourself based on factors such as the size of the data that reallo= c needs to copy (obtained through `malloc_usable_size`), the size that we actually need to cop= y when we doing malloc-memcpy-free ourself (minimalC= opyBytes) and the chance of= merging chunks (small blocks) or mremap (large blocks) in the underlayer = realloc. So, this is a real scenario, we need to call= `malloc_usable_size` frequently.

Example: We allocate a block of 500KB (mal= loc actually allocated 512KB) and want to extend it to 576KB via realloc. At this point realloc may downgrade back to the inefficient malloc(75= 6KB), memcpy(512KB) and free(512KB) modes. But the real situation at this time may be that we = only need to keep the first 4KB of content in 500KB, so we comprehensively= evaluate the cost (including the possibility = of realloc using block merging like in musl 1.1, and techniques like mrema= p to avoid copying) t= o decide whether to complete malloc(576KB), memcpy(**4KB**), free(512KB) b= y ourselves are more cost-effective.

Such optimizations hav= e measurable and significant effects on our practical applications in each= of the above libc environments.

In this scenario, w= e need to get the 512KB actually allocated by malloc through malloc_usable= _size instead of the 500KB length we saved ourselves.
<= div>
Thanks :-= )

=0A
--

   Best Regards  BaiYang
  baiyan= g@gmail.com
  http://i.baiy.= cn
**** = < END OF EMAIL > **** 
 
 
= From: Rich Felker
Date: 2022-09-20 03:18
To: baiyang
CC: musl
Subject:&n= bsp;Re: Re: [musl] The heap memory performance (malloc/free/realloc) is si= gnificantly degraded in musl 1.2 (compared to 1.1)
<= div>On Tue, Sep 20, 2022 at 02:44:58AM +0800, baiyang wrote:
=0A
= > > Is there a reason you're relying on an unreliable and nonstandar= d
=0A
> > function (malloc_usable_size) to do this rather t= han your program
=0A
> > keeping track of its own knowledge= of the allocated size? This is what
=0A
> > the C language= expects you to do. For example if you have a structure
=0A
> = > that contains a pointer to a dynamically sized buffer, normally you=0A
> > store the size in a size_t member right next to that= pointer, allowing
=0A
> > you to make these kind of decisi= ons without having to probe anything.
=0A
>
=0A
>= Yes, as I have been said, by comparing the number of bytes that
=0A<= div>> realloc needs to copy in the worst case (the return value of=0A
> malloc_usable_size), and the number of bytes we actually nee= d to
=0A
> copy, we can optimize the performance of realloc in= real scenarios
=0A
> and avoid unnecessary memory copies.=0A
 
=0A
You can do exactly the same keeping track of= the size yourself. The
=0A
only correct value malloc_usable_size= can return is the value you
=0A
passed to the allocator. If it's= returning a different size, your
=0A
malloc implementation has a= problem that will make you commit UB when
=0A
you use the result= of malloc_usable_size. Many real-world ones do have
=0A
this pro= blem.
=0A
 
=0A
> In fact, in scenarios includin= g glibc, tcmalloc, windows crt, mac os
=0A
> x, uclibc and mus= l 1.1, we did achieve good optimization results.
=0A
>
= =0A
> On the other hand, of course we keep the number of bytes actu= ally
=0A
> allocated, but it doesn't really reflect objectivel= y the number of
=0A
> bytes to be copied by realloc when the m= emcpy actually occurs. And
=0A
> malloc_usable_size() more acc= urately reflects how many bytes realloc
=0A
> needs to copy wh= en it degenerates back to malloc-memcpy-free mode.
=0A
 =0A
I don't understand your claim here. The size you would store is<= /div>=0A
exactly the size that realloc would have to copy. It if copie= s more,
=0A
that's just realloc being inefficient, but the differ= ence is not going
=0A
to be material anyway.
=0A
 <= /div>=0A
> So our expectation is as mentioned in the man page for l= inux, mac os
=0A
> or windows: "The value returned by malloc_u= sable_size() may be
=0A
> **greater than** the requested size = of the allocation" or "The
=0A
> memory block size is always a= t least as large as the allocation it
=0A
> backs, **and may b= e larger**." - We expect to get its internal size
=0A
> to eva= luate the cost of memory copying.
=0A
 
=0A
It's so= unding more and more like you did premature optimization
=0A
with= out measuring any of this, since there is *no way* the possible
=0Aamount of excess copying a realloc implementation might make
=0Ainternally could cost more than an extra external function call to=0A
malloc_usable_size (even if it did nothing but return).
=0A<= div> 
=0A
Rich
=0A
=0A ------=_001_NextPart457751300562_=------