[U-Boot] [PATCH 0/3] arm: reduce .bss section clear time

[Przemyslaw Marczak <p.marczak@samsung.com>]

Hello Simon,

On 02/02/2015 07:15 PM, Simon Glass wrote:
> Hi Lukasz,
>
> On 2 February 2015 at 01:46, Lukasz Majewski <l.majewski@samsung.com> 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.
>
> Regards,
> Simon
>

Filling the malloc area with some pattern was a good idea to find out, 
why my trats2 had some issue after skip the memset with zeros in malloc 
init.

And actually the issue was not in malloc call, but it was in calloc.

The present implementation assumes that memory reserved for malloc
is zeroed at init. And the calloc do the check, how much of the 
allocated memory is fresh(doesn't require zeroing).

After skip this fresh memory check, the calloc works fine.

Anyway, I think that this should be optional and tested on every config, 
before enable.

I would like to test something and will send the updated patch set on 
Monday.

Best regards,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com