From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Thu, 05 Feb 2015 10:51:00 +0100 Subject: [U-Boot] [PATCH 0/3] arm: reduce .bss section clear time In-Reply-To: References: <1422449743-10119-1-git-send-email-p.marczak@samsung.com> <54CA6442.7080902@samsung.com> <20150202094615.4779647c@amdc2363> Message-ID: <20150205105100.435e62fc@amdc2363> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, > Hi Lukasz, > > On 2 February 2015 at 01:46, Lukasz Majewski > wrote: > > Dear All, > > > >> And the next is interesting. > >> odroid_defconfig has more than 80MB for malloc (we need about > >> 64mb for the DFU now, to be able write 32MB file). > >> > >> This is the CONFIG_SYS_MALLOC_LEN. And the memory area for malloc > >> is set to 0 in function mem_malloc_init(). So for this config that > >> function sets more than 80MB to zero. > >> > >> This is not good, because we shouldn't expect zeroed memory > >> returned by malloc pointer. This is a job for calloc. > >> > >> Especially if some command expects zeroed memory after malloc, > >> probably after few next calls - it can crash... > > > > I think that the above excerpt is _really_ important and should be > > discussed. > > > > I've "cut" it from the original post, so it won't get lost between > > the lines. > > > > It seems really strange, that malloc() area is cleared after > > relocation. Which means that all "first" malloc'ed buffers get > > implicitly zeroed. > > > > Przemek is right here that this zeroing shouldn't be performed. > > > > I'm also concerned about potential bugs, which show up (or even > > worse - won't show up soon) after this change. > > > > Hence, I would like to ask directly the community about the possible > > solutions. > > > > Please look at: ./common/dlmalloc.c mem_alloc_init() function [1]. > > > > On the one hand removing memset() at [1] speeds up booting time and > > makes malloc() doing what is is supposed to do. > > > > On the other hand there might be in space some boards, which rely on > > this memset and without it some wired things may start to happening. > > I think removing it is a good idea. It was one optimisation that I did > for boot time in the Chromium tree. If you do it now (and Tom agrees) > then there is plenty of time to test for this release cycle. You could > go further and add a test CONFIG which fills it with some other > non-zero value. Tom, is such approach acceptable for you? > > Regards, > Simon -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group