[U-Boot] [PATCH] malloc_simple: Add simple malloc free function

[Chin Liang See <clsee@altera.com>]

On Wed, 2016-08-03 at 15:57 +0200, Marek Vasut wrote:
> On 08/03/2016 03:41 PM, Chin Liang See wrote:
> > On Wed, 2016-08-03 at 09:53 +0200, Marek Vasut wrote:
> > > On 08/03/2016 09:30 AM, Chin Liang See wrote:
> > > > Hi Marek,
> > > 
> > > Hi,
> > > 
> > > > On Wed, 2016-08-03 at 08:58 +0200, Marek Vasut wrote:
> > > > > On 08/03/2016 05:24 AM, Chin Liang See wrote:
> > > > > > Enable a simple malloc implementation which will minimize
> > > > > > memory usage prior relocation. This is essential as memory
> > > > > > available prior location is internal memory and limited in
> > > > > > size.
> > > > > > 
> > > > > > This implementation will stored last 2 usage of malloc.
> > > > > > When
> > > > > > free is invoked and the free address matched, we shall
> > > > > > revert
> > > > > > to previous value of gd->malloc_ptr that we stored.
> > > > > 
> > > > > This looks unnecessarily convoluted and fragile design.
> > > > > What problem do you observe and on what platform ?
> > > > 
> > > > Actually this for our Arria10 SoC device. In order to get DDR
> > > > working,
> > > > we need to program FPGA. To improve the usability, we put the
> > > > FPGA
> > > > programming file (RBF) into FAT partition.
> > > > 
> > > > In that sense, we would need to use FAT driver prior relocation
> > > > /
> > > > DDR
> > > > available. Due to that, the malloc usage is high and memory
> > > > available
> > > > is limited prior DDR available. 
> > > 
> > > I was under the impression that you have 256kiB of SRAM on the
> > > A10.
> > > SPL should consume about 64 kiB tops, including support for
> > > loading
> > > from VFAT. So you have 192 kiB available, how is that not enough
> > > ?
> > 
> > But I presume we won't want to limit that minimum 256MB of internal
> > memory needed for simple malloc usage, right?
> 
> Err, 256 MiB ? I think 192k of malloc area must be _plenty_ for SPL
> either way you slice it.
> 
> > > 
> > > > The simple malloc helps but without the free, its consumed way
> > > > too
> > > > much
> > > > memory than saving. Hence this simple malloc free patch help.
> > > > So I
> > > > believe this would benefits those who are executing complex
> > > > operation
> > > > prior relocation :) 
> > > 
> > > I believe you need to identify who is calling malloc() to obtain
> > > big
> > > buffers without recycling them.
> > > 
> > 
> > It's the fat driver which is utilizing the malloc.
> 
> So fat is allocating stuff without freeing it ? I wonder if we should
> either fix fat or use full malloc in SPL on A10 . I am not really
> fond
> of adding more stuff into simple malloc (to keep it small and 
> simple).

Actually fat driver is good where it invoke malloc and free during the
operation. Just that with existing malloc, there is no free
implementation and memory keep "push" every time malloc invoked.

> 
> > > Your design breaks in the scenario where someone does big malloc
> > > followed by two small mallocs if I understand it correctly. This
> > > doesn't scale and is a hack.
> > > 
> > 
> > Actually the proposed free is a simple implementation which acts as
> > stack push and pop with depth of 2. This is to enhance existing
> > implementation which don't handle the pop. This get worst
> > especially
> > dealing with fat driver.
> 
> Well, how does it handle my example? It doesn't and it fails to help
> in
> such case, right ?

I was thinking what is the correct depth while trying to keep things
simple. From the FAT access testing with SD and eMMC, depth of 2 works
well by cutting lot of memory consumption by simple malloc
implementation. Any thoughts whether should have more flexibility?

Thanks
Chin Liang

> 
> > Thanks
> > Chin Liang
> > 
> > > > Thanks
> > > > Chin Liang
> > > > 
> > > 
> > > 
> 
>