Re: [PATCH 07/31] lmb: Add reserve_lmb/free_lmb

From: Yinghai Lu
Date: Tue Mar 30 2010 - 02:14:37 EST


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
4. current lmb_alloc only honor limit, and doesn't honor low limit.

another usage is: for temporary buffer, like range array for subtraction.
we don't need to do free later.

>
> Ie. It should all be one single find/allocation function.
>
> In fact, you want to split lmb_find from lmb_reserve, then just make
> lmb_alloc use the above, I don't want 2 implementations of the same
> thing (maybe call it __lmb_find to expose the fact that it's a low level
> function to avoid for normal use).

that is some difference between them, and lmb_alloc doesn't honor low limit.

we can provide
lmb_find_area
lmb_reserve_area
lmb_free_area

and use lmb_find_area + lmb_reserve_area to get one lmb_alloc()

x86 sometime is using find_lmb_area to find big area, and use those area and later reserve actually used area.

you could use lmb_alloc, and later lmb_free not used. that is equal to lmb_find + lmb_reserve + lmb_free ...

Thanks

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