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

[Lukasz Majewski <l.majewski@samsung.com>]

Hi Simon,

> 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.

Tom, is such approach acceptable for you?

> 
> Regards,
> Simon



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group