mailing list of musl libc
 help / color / mirror / code / Atom feed
From: baiyang <baiyang@gmail.com>
To: "Rich Felker" <dalias@libc.org>
Cc: musl <musl@lists.openwall.com>
Subject: Re: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1)
Date: Tue, 20 Sep 2022 04:17:20 +0800	[thread overview]
Message-ID: <2022092004171908873459@gmail.com> (raw)
In-Reply-To: <20220919200744.GW9709@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 5609 bytes --]

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

thanks

--

   Best Regards
  BaiYang
  baiyang@gmail.com
  http://i.baiy.cn
**** < END OF EMAIL > **** 
 
 
From: Rich Felker
Date: 2022-09-20 04:07
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 03:45:35AM +0800, baiyang wrote:
> > The only correct value malloc_usable_size can return is the value
> > you passed to the allocator.
> 
> I don't think so, see:
> 
> Linux man page:
> https://man7.org/linux/man-pages/man3/malloc_usable_size.3.html -
> "The value returned by malloc_usable_size() may be **greater than**
> the requested size of the allocation".
> 
> Mac OS X man page:
> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/malloc_size.3.html
> - "The memory block size is always at least as large as the
> allocation it backs, **and may be larger**."
> 
> FreeBSD man page:
> https://www.freebsd.org/cgi/man.cgi?query=malloc_usable_size&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE&format=html
> - "The return value **may be larger** than the size that was
> requested during allocation".
> 
> These official man pages clearly state that the return value of
> malloc_usable_size is the size of the memory block allocated
> internally, not the size submitted by the user.
> 
> Instead, we didn'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.
 
OK, I didn't state that precisely. There are two conflicting claims
for what the malloc_usable_size contract is. If it's allowed to return
some value larger than the size you requested, then the size returned
is not actually "usable" and there's basically nothing useful you can
do with the function.
 
> > It's sounding more and more like you did premature optimization
> > without measuring any of this, since there is *no way* the possible
> > amount of excess copying a realloc implementation might make
> > internally 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
> > frequently: we need to optimize the realloc experience. We add an
> > extra parameter to realloc - minimalCopyBytes: 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 realloc needs to copy (obtained through
> > `malloc_usable_size`), the size that we actually need to copy when
> > we doing malloc-memcpy-free ourself (minimalCopyBytes) 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 (malloc actually allocated
> 512KB) and want to extend it to 576KB via realloc. At this point
> realloc may downgrade back to the inefficient malloc(756KB),
> memcpy(512KB) and free(512KB) modes.
 
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.
 
> 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 mremap to avoid copying) to decide whether to
> complete malloc(576KB), memcpy(**4KB**), free(512KB) by ourselves
> are more cost-effective.
 
You could have achieved exactly the same thing by keeping your own
knowledge that you allocated 500kB. But it would still be
significantly slower, because mmap+memcpy+munmap (2 syscalls) is
slower than mremap (1 syscall).
 
> Such optimizations have measurable and significant effects on our
> practical applications in each of the above libc environments.
> 
> In this scenario, we need to get the 512KB actually allocated by
> malloc through malloc_usable_size instead of the 500KB length we
> saved ourselves.
 
No you don't. Either number works just as well (or rather just as
poorly).
 
Rich

[-- Attachment #2: Type: text/html, Size: 10503 bytes --]

  reply	other threads:[~2022-09-19 20:17 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-19  7:53 baiyang
2022-09-19 11:08 ` Szabolcs Nagy
2022-09-19 12:36   ` Florian Weimer
2022-09-19 13:46     ` Rich Felker
2022-09-19 13:53       ` James Y Knight
2022-09-19 17:40         ` baiyang
2022-09-19 18:14           ` Szabolcs Nagy
2022-09-19 18:40             ` baiyang
2022-09-19 19:07             ` Gabriel Ravier
2022-09-19 19:21               ` Rich Felker
2022-09-19 21:02                 ` Gabriel Ravier
2022-09-19 21:47                   ` Rich Felker
2022-09-19 22:31                     ` Gabriel Ravier
2022-09-19 22:46                       ` baiyang
2022-09-19 20:46             ` Nat!
2022-09-20  8:51               ` Szabolcs Nagy
2022-09-20  0:13           ` James Y Knight
2022-09-20  0:25             ` baiyang
2022-09-20  0:38               ` Rich Felker
2022-09-20  0:47                 ` baiyang
2022-09-20  1:00                   ` Rich Felker
2022-09-20  1:18                     ` baiyang
2022-09-20  2:15                       ` Rich Felker
2022-09-20  2:35                         ` baiyang
2022-09-20  3:28                           ` Rich Felker
2022-09-20  3:53                             ` baiyang
2022-09-20  5:41                               ` Rich Felker
2022-09-20  5:56                                 ` baiyang
2022-09-20 12:16                                   ` Rich Felker
2022-09-20 17:21                                     ` baiyang
2022-09-20  8:33       ` Florian Weimer
2022-09-20 13:54         ` Siddhesh Poyarekar
2022-09-20 16:59           ` James Y Knight
2022-09-20 17:34             ` Szabolcs Nagy
2022-09-20 19:53               ` James Y Knight
2022-09-24  8:55               ` Fangrui Song
2022-09-20 17:39             ` baiyang
2022-09-20 18:12               ` Quentin Rameau
2022-09-20 18:19                 ` Rich Felker
2022-09-20 18:26                   ` Alexander Monakov
2022-09-20 18:35                     ` baiyang
2022-09-20 20:33                       ` Gabriel Ravier
2022-09-20 20:45                         ` baiyang
2022-09-21  8:42                           ` NRK
2022-09-20 18:37                     ` Quentin Rameau
2022-09-21 10:15                   ` [musl] " 王志强
2022-09-21 16:11                     ` [musl] " 王志强
2022-09-21 17:15                     ` [musl] " Rich Felker
2022-09-21 17:58                       ` Rich Felker
2022-09-22  3:34                         ` [musl] " 王志强
2022-09-22  9:10                           ` [musl] " 王志强
2022-09-22  9:39                             ` [musl] " 王志强
2022-09-20 17:28           ` baiyang
2022-09-20 17:44             ` Siddhesh Poyarekar
2022-10-10 14:13           ` Florian Weimer
2022-09-19 13:43 ` Rich Felker
2022-09-19 17:32   ` baiyang
2022-09-19 18:15     ` Rich Felker
2022-09-19 18:44       ` baiyang
2022-09-19 19:18         ` Rich Felker
2022-09-19 19:45           ` baiyang
2022-09-19 20:07             ` Rich Felker
2022-09-19 20:17               ` baiyang [this message]
2022-09-19 20:28                 ` Rich Felker
2022-09-19 20:38                   ` baiyang
2022-09-19 22:02                 ` Quentin Rameau
2022-09-19 20:17             ` Joakim Sindholt
2022-09-19 20:33               ` baiyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2022092004171908873459@gmail.com \
    --to=baiyang@gmail.com \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).