lkml.org 
[lkml]   [2010]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: lmb type features.
    From
    Date
    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 ?

    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.

    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.

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

    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.

    Cheers,
    Ben.

    > Thanks
    >
    > Yinghai
    >
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/




    \
     
     \ /
      Last update: 2010-05-17 02:51    [W:4.075 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site