public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: "Torbjörn SVENSSON" <torbjorn.svensson@foss.st.com>
To: <newlib@sourceware.org>
Cc: "Torbjörn SVENSSON" <torbjorn.svensson@foss.st.com>
Subject: [PATCH 2/2] Don't allocate another header when merging chunks
Date: Tue, 30 Aug 2022 15:56:26 +0200	[thread overview]
Message-ID: <20220830135625.2247198-2-torbjorn.svensson@foss.st.com> (raw)
In-Reply-To: <20220830135625.2247198-1-torbjorn.svensson@foss.st.com>

In the nano version of malloc, when the last chunk is to be extended,
there is no need to acount for the header again as it's already taken
into account in the overall "alloc_size" at the beginning of the
function.

Contributed by STMicroelectronics

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
---
 newlib/libc/stdlib/nano-mallocr.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/newlib/libc/stdlib/nano-mallocr.c b/newlib/libc/stdlib/nano-mallocr.c
index 43eb20e07..b2273ba60 100644
--- a/newlib/libc/stdlib/nano-mallocr.c
+++ b/newlib/libc/stdlib/nano-mallocr.c
@@ -328,10 +328,6 @@ void * nano_malloc(RARG malloc_size_t s)
                /* The last free item has the heap end as neighbour.
                 * Let's ask for a smaller amount and merge */
                alloc_size -= p->size;
-               alloc_size = ALIGN_SIZE(alloc_size, CHUNK_ALIGN); /* size of aligned data load */
-               alloc_size += MALLOC_PADDING; /* padding */
-               alloc_size += CHUNK_OFFSET; /* size of chunk head */
-               alloc_size = MAX(alloc_size, MALLOC_MINCHUNK);
 
                if (sbrk_aligned(RCALL alloc_size) != (void *)-1)
                {
-- 
2.25.1


WARNING: multiple messages have this Message-ID
From: "Torbjörn SVENSSON" <torbjorn.svensson@foss.st.com>
To: <newlib@sourceware.org>
Subject: [PATCH 2/2] Don't allocate another header when merging chunks
Date: Tue, 30 Aug 2022 15:56:26 +0200	[thread overview]
Message-ID: <20220830135625.2247198-2-torbjorn.svensson@foss.st.com> (raw)
Message-ID: <20220830135626.wmJS3aaG4EkTXTEJ5DhWgRn_LPQQ8Bnh4XMF0IV3tOs@z> (raw)
In-Reply-To: <20220830135625.2247198-1-torbjorn.svensson@foss.st.com>

In the nano version of malloc, when the last chunk is to be extended,
there is no need to acount for the header again as it's already taken
into account in the overall "alloc_size" at the beginning of the
function.

Contributed by STMicroelectronics

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
---
 newlib/libc/stdlib/nano-mallocr.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/newlib/libc/stdlib/nano-mallocr.c b/newlib/libc/stdlib/nano-mallocr.c
index 43eb20e07..b2273ba60 100644
--- a/newlib/libc/stdlib/nano-mallocr.c
+++ b/newlib/libc/stdlib/nano-mallocr.c
@@ -328,10 +328,6 @@ void * nano_malloc(RARG malloc_size_t s)
                /* The last free item has the heap end as neighbour.
                 * Let's ask for a smaller amount and merge */
                alloc_size -= p->size;
-               alloc_size = ALIGN_SIZE(alloc_size, CHUNK_ALIGN); /* size of aligned data load */
-               alloc_size += MALLOC_PADDING; /* padding */
-               alloc_size += CHUNK_OFFSET; /* size of chunk head */
-               alloc_size = MAX(alloc_size, MALLOC_MINCHUNK);
 
                if (sbrk_aligned(RCALL alloc_size) != (void *)-1)
                {
-- 
2.25.1


  parent reply	other threads:[~2022-08-30 13:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 13:56 [PATCH 1/2] Used chunk needs to be removed from free_list Torbjörn SVENSSON
2022-08-30 13:56 ` Torbjörn SVENSSON
2022-08-30 13:56 ` Torbjörn SVENSSON [this message]
2022-08-30 13:56   ` [PATCH 2/2] Don't allocate another header when merging chunks Torbjörn SVENSSON
2022-09-01 18:44   ` Jeff Johnston
2022-09-01 19:04     ` Torbjorn SVENSSON
2022-09-01 19:36       ` Jeff Johnston
2022-09-01 19:39   ` Jeff Johnston
2022-09-01 18:41 ` [PATCH 1/2] Used chunk needs to be removed from free_list Jeff Johnston

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=20220830135625.2247198-2-torbjorn.svensson@foss.st.com \
    --to=torbjorn.svensson@foss.st.com \
    --cc=newlib@sourceware.org \
    /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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).