Re: memblock versus bootmem (relevant for sparc32?)

[Yinghai Lu <yinghai@kernel.org>]

On 04/24/2011 01:22 AM, Sam Ravnborg wrote:
> Hi Ben.
> 
> On Sun, Apr 24, 2011 at 09:20:46AM +1000, Benjamin Herrenschmidt wrote:
>> On Sat, 2011-04-23 at 19:42 +0200, Sam Ravnborg wrote:
>>> Hi Ben, Yinghai, Ingo.
>>>
>>> While doing some sparc related tasks I noticed that sparc64
>>> uses memblock - whereas sparc32 does not.
>>>
>>> I am aware that memblock was called lmb in the older days and
>>> that sparc64 had lmb support which was converted to memblock support.
>>>
>>> But so far I have failed to find any information on what the benefit
>>> of memblock is and how it compared to for example bootmem.
>>> I can see that x86 no longer uses bootmem - as the only arch.
>>
>> Mostly memblock works earlier and handles both the actual physical
>> memory layout and allocation within that memory. Archs like powerpc
>> still use memblock, then bootmem, then page alloc.
>>
>> x86 eventually removed the bootmem step in the middle, which is a good
>> thing, unfortunately...
>>
>>> But I also noticed that mm/nobootmem.c contains several functions
>>> named bla_x86_bla(). So I continued to be a bit confused.
>>
>>  ... as you noticed, this is all quite horrible with x86 junk in generic
>> places etc... and so I haven't yet looked at doing that on powerpc as
>> well (though I'd like to at some stage).
>>  
>>> Do there exist any writeup of what memblock is?
>>
>> Other than the code ? :-) It's a very simple region list management
>> which works on two lists, one represents the physical memory in the
>> system and the other represents reserved areas and can be used as an
>> allocator (or to reserve "FW" regions etc...).
>>
>> It initially worked entirely on static arrays (it used to be that way so
>> it can be used very early during boot), but it now grew the ability to
>> re-allocate its own arrays so that it can be used more generically as an
>> allocator instead of bootmem.
>>
>> It's probably slower than bootmem tho, but on the other hand it
>> shouldn't be on any critical path.
> 
> Seems that my initial impression is OK. But I was confused by the x86
> specific parts.

that three references _x86_ in nobootmem.c

mm/nobootmem.c: memblock_x86_reserve_range(addr, addr + size, "BOOTMEM");
mm/nobootmem.c: memblock_x86_free_range(physaddr, physaddr + size);
mm/nobootmem.c: memblock_x86_free_range(addr, addr + size);


and difference to memblock_reserve/free is debug printing, and do not panic if start=end.

void __init memblock_x86_reserve_range(u64 start, u64 end, char *name)
{
        if (start = end)
                return;

        if (WARN_ONCE(start > end, "memblock_x86_reserve_range: wrong range [%#llx, %#llx)\n", start, end))
                return;

        memblock_dbg("    memblock_x86_reserve_range: [%#010llx-%#010llx] %16s\n", start, end - 1, name);

        memblock_reserve(start, end - start);
}

void __init memblock_x86_free_range(u64 start, u64 end)
{
        if (start = end)
                return;

        if (WARN_ONCE(start > end, "memblock_x86_free_range: wrong range [%#llx, %#llx)\n", start, end))
                return;

        memblock_dbg("       memblock_x86_free_range: [%#010llx-%#010llx]\n", start, end - 1);

        memblock_free(start, end - start);
}


> 
>>
>>> Also does it make sense to consider introducing memblock for sparc32.
>>> And if yes - what is the benefit and what does it replace?
> 
> I have digged a bit deeper in the code now. sparc32 has a local implementation
> that handle the availabe memory which it then handed over to bootmem.
> It would be a nice cleanup to get this local implementation migrated
> over to memblock. Both in terms of using generic code but also
> to be more aligned with sparc64.
> 
> Replacing bootmem seems like a bigger task - that will wait.

will need to move get_free_all_memory_range() and related funcs from arch/x86/mm/memblock.c to mm/memblock.c or mm/nobootmem.c

replacing bootmem with memblock in arch code should be simple.


Thanks

Yinghai