From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id 28C173851C3A for ; Tue, 30 Aug 2022 13:57:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 28C173851C3A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0288072.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27U9PxDI017483 for ; Tue, 30 Aug 2022 15:57:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=selector1; bh=0OVQBT75oYmM/hRDUIxMV8WjZHak+Puz/tEUaOXIsHM=; b=XJKyJVg+GV/EphBwR01LfR/jwBfwhZmtlMjVxQtPT6R9tbPJXbkPLAeiOlvlqlTFJ1vE UCx89cQEYR+hBsbNWor5iMn0VBSnAuudXAH+EZdgoksXggcIazjm7EGeud/DAbtoBvhY uQapoeBVGECSF94ddfm+nbZzA9dMQjlWCVZUk064qHTJ5cyTusUL1FLnQKjaAIK/3Lyp YRjnyUKHUbUEBcDUTqxv+hfdiT0lFfOg16IE8j8PeEFPh15zV/OLb7wpOtFXqSYrv857 vbG54oBRkqaEst1CZtcniKBPA5qjm7qpM+SerQhkSrV08lVOLGlMGzd1ICGe1RxfpLlG yA== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3j78pk8gu0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 30 Aug 2022 15:57:15 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 7B88A10002A for ; Tue, 30 Aug 2022 15:57:15 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 774F522A6FD for ; Tue, 30 Aug 2022 15:57:15 +0200 (CEST) Received: from jkgcxl0002.jkg.st.com (10.75.127.120) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2375.7; Tue, 30 Aug 2022 15:57:13 +0200 From: =?UTF-8?q?Torbj=C3=B6rn=20SVENSSON?= To: CC: =?UTF-8?q?Torbj=C3=B6rn=20SVENSSON?= Subject: [PATCH 2/2] Don't allocate another header when merging chunks Date: Tue, 30 Aug 2022 15:56:26 +0200 Message-ID: <20220830135625.2247198-2-torbjorn.svensson@foss.st.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220830135625.2247198-1-torbjorn.svensson@foss.st.com> References: <20220830135625.2247198-1-torbjorn.svensson@foss.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.75.127.120] X-ClientProxiedBy: GPXDAG2NODE4.st.com (10.75.127.68) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-30_08,2022-08-30_01,2022-06-22_01 X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,GIT_PATCH_0,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 --- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id 28C173851C3A for ; Tue, 30 Aug 2022 13:57:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 28C173851C3A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0288072.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27U9PxDI017483 for ; Tue, 30 Aug 2022 15:57:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=selector1; bh=0OVQBT75oYmM/hRDUIxMV8WjZHak+Puz/tEUaOXIsHM=; b=XJKyJVg+GV/EphBwR01LfR/jwBfwhZmtlMjVxQtPT6R9tbPJXbkPLAeiOlvlqlTFJ1vE UCx89cQEYR+hBsbNWor5iMn0VBSnAuudXAH+EZdgoksXggcIazjm7EGeud/DAbtoBvhY uQapoeBVGECSF94ddfm+nbZzA9dMQjlWCVZUk064qHTJ5cyTusUL1FLnQKjaAIK/3Lyp YRjnyUKHUbUEBcDUTqxv+hfdiT0lFfOg16IE8j8PeEFPh15zV/OLb7wpOtFXqSYrv857 vbG54oBRkqaEst1CZtcniKBPA5qjm7qpM+SerQhkSrV08lVOLGlMGzd1ICGe1RxfpLlG yA== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3j78pk8gu0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 30 Aug 2022 15:57:15 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 7B88A10002A for ; Tue, 30 Aug 2022 15:57:15 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 774F522A6FD for ; Tue, 30 Aug 2022 15:57:15 +0200 (CEST) Received: from jkgcxl0002.jkg.st.com (10.75.127.120) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2375.7; Tue, 30 Aug 2022 15:57:13 +0200 From: =?UTF-8?q?Torbj=C3=B6rn=20SVENSSON?= To: Subject: [PATCH 2/2] Don't allocate another header when merging chunks Date: Tue, 30 Aug 2022 15:56:26 +0200 Message-ID: <20220830135625.2247198-2-torbjorn.svensson@foss.st.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220830135625.2247198-1-torbjorn.svensson@foss.st.com> References: <20220830135625.2247198-1-torbjorn.svensson@foss.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.75.127.120] X-ClientProxiedBy: GPXDAG2NODE4.st.com (10.75.127.68) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-30_08,2022-08-30_01,2022-06-22_01 X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2022 13:57:22 -0000 Message-ID: <20220830135626.wmJS3aaG4EkTXTEJ5DhWgRn_LPQQ8Bnh4XMF0IV3tOs@z> 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 --- 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