Prev: [PATCH 8/8] staging: vt6656: tcrc.c: Fixed coding style issues
Next: [PATCH 0/2] perf: Use LBR for machine/oops debugging
From: Benjamin Herrenschmidt on 30 Mar 2010 01:30
On Mon, 2010-03-29 at 16:53 -0700, Yinghai Lu wrote:
>
> ok, can i reuse rmo_size, or introduce one new member in struct lmb.
>
> default_limit?

lmb.default_limit sounds good to me.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 30 Mar 2010 01:40
On Mon, 2010-03-29 at 21:21 -0700, Yinghai Lu wrote:
>
> if someone want to find some area, but not going to access that range,
> then we should let them alloc it.
>
> how about access_limit?

No, no you don't get it. default_alloc_limit is fine. It's the -default-
limit. It doesn't apply to lmb_alloc_base() that takes an explicit
limit...

Something along those lines.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 30 Mar 2010 01:50
On 03/29/2010 10:29 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2010-03-29 at 21:21 -0700, Yinghai Lu wrote:
>>
>> if someone want to find some area, but not going to access that range,
>> then we should let them alloc it.
>>
>> how about access_limit?
>
> No, no you don't get it. default_alloc_limit is fine. It's the -default-
> limit. It doesn't apply to lmb_alloc_base() that takes an explicit
> limit...
>
fine, will use default_limit.

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 30 Mar 2010 02:20
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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 30 Mar 2010 02:30
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.

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).

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [PATCH 8/8] staging: vt6656: tcrc.c: Fixed coding style issues
Next: [PATCH 0/2] perf: Use LBR for machine/oops debugging