From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Wed, 25 Nov 2015 14:32:24 +0100 Subject: [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size In-Reply-To: <5655B461.1000801@samsung.com> References: <1448052204-4928-1-git-send-email-marex@denx.de> <201511251316.12152.marex@denx.de> <5655B461.1000801@samsung.com> Message-ID: <201511251432.25058.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wednesday, November 25, 2015 at 02:15:13 PM, Przemyslaw Marczak wrote: > On 11/25/2015 01:16 PM, Marek Vasut wrote: > > On Wednesday, November 25, 2015 at 01:00:41 PM, Przemyslaw Marczak wrote: > >> Hello Marek, > >> > >> On 11/25/2015 11:56 AM, Marek Vasut wrote: > >>> On Wednesday, November 25, 2015 at 11:40:36 AM, Przemyslaw Marczak wrote: > >>>> Hello Tim, Marek > >>>> > >>>> On 11/20/2015 10:40 PM, Tim Harvey wrote: > >>>>> On Fri, Nov 20, 2015 at 12:43 PM, Marek Vasut wrote: > >>>>>> Using 50 MiB malloc pool in SPL is nonsense. Since the caches are > >>>>>> not enabled in SPL, it takes 2 seconds to init the pool and has no > >>>>>> obvious benefit. Reduce the size to 1 MiB. > >>>>>> > >>>>>> Signed-off-by: Marek Vasut > >>>>>> Cc: Stefano Babic > >>>>>> Cc: Tim Harvey > >>>>>> --- > >>>>>> > >>>>>> include/configs/imx6_spl.h | 6 +++--- > >>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) > >>>>>> > >>>>>> diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h > >>>>>> index 1744f2c..43ce7fe 100644 > >>>>>> --- a/include/configs/imx6_spl.h > >>>>>> +++ b/include/configs/imx6_spl.h > >>>>>> @@ -63,15 +63,15 @@ > >>>>>> > >>>>>> #if defined(CONFIG_MX6SX) || defined(CONFIG_MX6UL) || > >>>>>> defined(CONFIG_MX6SL) #define CONFIG_SPL_BSS_START_ADDR > >>>>>> 0x88200000 > >>>>>> > >>>>>> -#define CONFIG_SPL_BSS_MAX_SIZE 0x100000 /* 1 MB */ > >>>>>> +#define CONFIG_SPL_BSS_MAX_SIZE 0x100000 /* 1 > >>>>>> MB */ > >>>>>> > >>>>>> #define CONFIG_SYS_SPL_MALLOC_START 0x88300000 > >>>>>> > >>>>>> -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x3200000 /* 50 MB */ > >>>>>> +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x100000 /* 1 > >>>>>> MB */ > >>>>>> > >>>>>> #define CONFIG_SYS_TEXT_BASE 0x87800000 > >>>>>> #else > >>>>>> #define CONFIG_SPL_BSS_START_ADDR 0x18200000 > >>>>>> #define CONFIG_SPL_BSS_MAX_SIZE 0x100000 > >>>>>> /* 1 MB */ #define CONFIG_SYS_SPL_MALLOC_START 0x18300000 > >>>>>> > >>>>>> -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x3200000 /* 50 MB */ > >>>>>> +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x100000 /* 1 MB */ > >>>>>> > >>>>>> #define CONFIG_SYS_TEXT_BASE 0x17800000 > >>>>>> #endif > >>>>>> #endif > >>>>>> > >>>>>> -- > >>>>>> 2.1.4 > >>>>> > >>>>> Acked-by: Tim Harvey > >>>>> > >>>>> thanks for dropping 2 secs off our time to boot! > >>>>> > >>>>> Tim > >>>> > >>>> The boot time for SPL and U-Boot can be reduced more if > >>>> CONFIG_SYS_MALLOC_CLEAR_ON_INIT is unset (default is set). > >>> > >>> This might confuse DM, so I don't want this. DM checks if it's > >>> structures were already inited and if we don't clear the malloc area, > >>> they would be. > >> > >> DM is safe - it uses calloc() for it's structures and also driver's > >> static structures are zeroed. Only some private data which is not > >> allocated by DM can be risky to use. > >> > >> To be precise - we don't use malloc() to get pointer for zeroed memory, > >> this is the job for the calloc(). > >> > >> So any code with bad use of malloc() should be fixed ASAP. > >> > >> If you assume that clear the malloc pool at boot is safe to use, then > >> I'm asking you, what about the sequence malloc/free/malloc for > >> potentially the same area? You can't be sure that the second returned > >> pointer after calling free() - points to the initially zeroed pool. > >> > >> We don't clean the malloc pool for configs that we maintain and we > >> didn't noticed any issues related to this. And the boot time is reduced > >> significantly. > > > > Do you use DM in SPL ? > > No, we don't use the SPL - for the boards which we maintain. OK > > I just checked and I see it's probably only the GD which needs to be > > cleared out, so we should indeed be safe. In which case, patch is > > welcome to enable CONFIG_SYS_MALLOC_CLEAR_ON_INIT . > > Yes I can see also for the Exynos SPL, that GD is manually cleared. > > But disabling the default CONFIG_SYS_MALLOC_CLEAR_ON_INIT, will help you > in reducing the U-Boot init time. > Just try and if you can easy measure the real difference for > enable/disable this config - share the results - it can give us an > interesting conclusions. Sure, thanks for the hint, but I still don't see any reason for having 50 MiB malloc area in SPL ;-)