Re: lmb type features.

[Yinghai <yinghai.lu@oracle.com>]

On 05/16/2010 05:46 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2010-05-14 at 16:51 -0700, Yinghai wrote:
> 
>  .../...
> 
>> #define LMB_ADD_MERGE (1<<0) 
>> #define LMB_ARRAY_DOUBLE (1<<1)
>>
>> so before call double_lmb_array(), should check the features to bit is set or not.
>> otherwise should emit PANIC with clear message.
>>
>> Usage:
>>
>> for range replacement,
>>
>> 1. early stage before lmb.reserved, lmb.memory is there.
>> so can not use lmb_find_base yet.
> 
> Let me make sure I understand: You mean when doing all the memory
> lmb_add() early during boot, we haven't done the various lmb_reserve()
> for all potentially reserved areas and thus cannot rely on
> double_lmb_array() doing the right thing ?

yes, 

thinking to use lmb_type to replace struct for mtrr trimming

> 
> I think this is a good point. However, a better way to do that would
> be to set the default alloc limit to 0 instead of LMB_ALLOC_ANYWHERE.
> 
> I haven't done that yet though I certainly intend to, but I'll need
> to ensure all the archs using LMB set a decent limit at some stage. You
> can in the meantime do it explicitely in x86.
> 
> Additionally, it should be possible in most cases to do all the critical
> lmb_reserve() early, before lmb_add()'s, and thus remove the problem,
> though that is indeed not the case today.

need the initial array size is big enough to use lmb_reserve() early.

in my patchset, for x86, already call lmb_reserve() early, and later all lmb_add_memory()
to fill lmb.


> 
> It would be nice to be able to extend the array for memory addition
> since that would allow us to have much smaller static arrays in the
> first place.

not on x86, we could to put them in __init with them.

hotplug mem should use resource tree instead of lmb?


> 
>> 2. for bootmem replacement, when do range set subtraction for final free range list,
>> don't want to change lmb.reserved in the middle.  callee should make sure to have big
>> enough temperately lmb_regions in lmb_type. 
> 
> Sorry, I'm not sure I grasped your explanation above. You mean when
> transitioning from LMB to the page allocator, the page freeing needs to
> be done after substracting the reserved array from the memory, and that
> substraction might cause the arrays to increase in size, thus affecting
> the reserved array ?

right. 

> 
> That could be solved by not doing the substraction and doing things a
> bit differently. You could have a single function that walks both arrays
> at the same time, and calls a callback for all memory ranges it finds
> that aren't reserved. Not -that- tricky to code.

but need to make sure lmb.reserved doesn't have overlapped eentries.

will check that later.

Thanks

Yinghai