On 03/29/2010 11:46 PM, Michael Ellerman wrote: > On Mon, 2010-03-29 at 23:12 -0700, Yinghai Lu wrote: >> On 03/29/2010 10:26 PM, Benjamin Herrenschmidt wrote: >>> On Mon, 2010-03-29 at 17:03 -0700, Yinghai Lu wrote: >>>> >>>> in short: It could make us to avoid use the range that we are going to >>>> reserve, >>>> when we try to get new position new lmb.reserved.region. >>> >>> I'm not too sure I follow you. For the resizing, I would just basically >>> call a low level variant of alloc (__lmb_alloc ?) that explicitely >>> doesn't honor the total-2 "reserved" entries in the array. >> >> 1. you want to reserve rangeA >> 2. before that will check if region array is big enough, >> 3. if region is not big enough, will call lmb_alloc to get new range. >> lmb_alloc could return rangB that is overlapped with rangeA > > So instead you do it the other way. > > 1. you want to reserve rangeA > 2. you reserve rangeA > 3. if reserving rangeA consumed a slot in the array then you check if > you have at least two free slots. If not you realloc. You don't need any > special tricks because you have space to lmb_alloc() a new area and move > everything over. so that is check it later. should work. one less find_lmb_area user. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
