Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Sep 2022 02:35:17 +0800
From: baiyang <baiyang@...il.com>
To: musl <musl@...ts.openwall.com>
Cc: "Quentin Rameau" <quinq@...th.space>, 
	"Florian Weimer" <fweimer@...hat.com>
Subject: Re: Re: The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1)

> So what you're actually trying to do is more clear now.
> And this is something that you should do on the “application layer”,
> not expect the libc to magically taking care of this.

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

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

Yes, from malloc_usable_size, the size that the application layer actually needs to copy, and other parameters like the OS, allocator, etc. 

--

   Best Regards
  BaiYang
  baiyang@...il.com
  http://i.baiy.cn
**** < END OF EMAIL > **** 
 
 
From: Alexander Monakov
Date: 2022-09-21 02:26
To: musl
CC: Quentin Rameau; Florian Weimer
Subject: Re: [musl] The heap memory performance (malloc/free/realloc) is significantly degraded in musl 1.2 (compared to 1.1)
On Tue, 20 Sep 2022, Rich Felker wrote:
 
> Exactly. This can be done entirely at the application layer just by
> keeping track of the size you allocated. In the above example, the
> number 256 kB is a red herring. Yes the
> "malloc(300KB)+memcpy(256KB)+free(256KB)" is wasteful, but the
> "malloc(300KB)+memcpy(200KB)+free(200KB)" would be comparably wasteful
> when you only want to preserve the first 2K, and you can make the
> decision that it would be wasteful, and that you instead just want to
> allocate a new buffer yourself and memcpy 2K, just by knowing the
> original 200KB, without any knowledge of malloc_usable_size.
 
They want to know if realloc will resize the allocation in-place so
the internal memcpy will not happen.
 
AIUI, what they really need is not "usable_size", but "cost estimation
for resizing allocation at pointer P to size S". Which I believe they
try to deduce from malloc_usable_size.
 
Alexander

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.