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

[Marek Vasut]

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

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

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


-- 
Best regards,
Marek Vasut