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

[Marek Vasut]

On 08/04/2016 05:12 PM, Chin Liang See wrote:
> On Thu, 2016-08-04 at 07:30 +0200, Marek Vasut wrote:
>> On 08/03/2016 05:22 PM, Chin Liang See wrote:
>>
>> Hi,
> 
> Hi Marek,
> 
>>
>> [...]
>>>>> 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.
>>
>> And I agree with Simon that we should look into the FAT driver and
>> fix
>> it. Is that not possible ?
> 
> 
> Definitely as seems everyone believe this should be the right way to
> go.

Indeed

>>
>>>>>> 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?
>>
>> You still didn't answer my question -- how will this handle my
>> example
>> usecase ?
>>
> 
> I did and wonder my email server having issue again. For this case,
> yah, it will not being handle as we try to keep it simple by having
> depth of 2. FYI, the 2 is being derived from my experiment of FAT
> driver access with SD and eMMC devices. We can enhance that but
> probably that might not a good idea per Simon suggested.

How would you enhance it such that I cannot find counter-example ? :)

-- 
Best regards,
Marek Vasut