[PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order

[PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order

[Pintu Kumar]

The Android ion_system_heap uses allocation fallback mechanism
based on 8,4,0 order pages available in the system.
It changes gfp flags based on higher order allocation request.
This higher order value is hard-coded as 4, instead of using
the system defined higher order value.
Thus replacing this hard-coded value with PAGE_ALLOC_COSTLY_ORDER
which is defined as 3.
This will help mapping the higher order request in system heap with
the actual allocation request.

Signed-off-by: Pintu Kumar <pintu.k@samsung.com>
---
 drivers/staging/android/ion/ion_system_heap.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
index da2a63c..e6c393f 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -65,7 +65,7 @@ static struct page *alloc_buffer_page(struct ion_system_heap *heap,
 	} else {
 		gfp_t gfp_flags = low_order_gfp_flags;
 
-		if (order > 4)
+		if (order > PAGE_ALLOC_COSTLY_ORDER)
 			gfp_flags = high_order_gfp_flags;
 		page = alloc_pages(gfp_flags | __GFP_COMP, order);
 		if (!page)
@@ -276,7 +276,7 @@ struct ion_heap *ion_system_heap_create(struct ion_platform_heap *unused)
 		struct ion_page_pool *pool;
 		gfp_t gfp_flags = low_order_gfp_flags;
 
-		if (orders[i] > 4)
+		if (orders[i] > PAGE_ALLOC_COSTLY_ORDER)
 			gfp_flags = high_order_gfp_flags;
 		pool = ion_page_pool_create(gfp_flags, orders[i]);
 		if (!pool)
-- 
1.7.9.5

Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order

[Heesub Shin]

Hello Kumar,

On 10/06/2014 05:31 PM, Pintu Kumar wrote:
> The Android ion_system_heap uses allocation fallback mechanism
> based on 8,4,0 order pages available in the system.
> It changes gfp flags based on higher order allocation request.
> This higher order value is hard-coded as 4, instead of using
> the system defined higher order value.
> Thus replacing this hard-coded value with PAGE_ALLOC_COSTLY_ORDER
> which is defined as 3.
> This will help mapping the higher order request in system heap with
> the actual allocation request.

Quite reasonable.

Reviewed-by: Heesub Shin <heesub.shin@samsung.com>

BTW, Anyone knows how the allocation order (8,4 and 0) was decided? I 
think only Google guys might know the answer.

regards,
heesub

>
> Signed-off-by: Pintu Kumar <pintu.k@samsung.com>
> ---
>   drivers/staging/android/ion/ion_system_heap.c |    4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
> index da2a63c..e6c393f 100644
> --- a/drivers/staging/android/ion/ion_system_heap.c
> +++ b/drivers/staging/android/ion/ion_system_heap.c
> @@ -65,7 +65,7 @@ static struct page *alloc_buffer_page(struct ion_system_heap *heap,
>   	} else {
>   		gfp_t gfp_flags = low_order_gfp_flags;
>
> -		if (order > 4)
> +		if (order > PAGE_ALLOC_COSTLY_ORDER)
>   			gfp_flags = high_order_gfp_flags;
>   		page = alloc_pages(gfp_flags | __GFP_COMP, order);
>   		if (!page)
> @@ -276,7 +276,7 @@ struct ion_heap *ion_system_heap_create(struct ion_platform_heap *unused)
>   		struct ion_page_pool *pool;
>   		gfp_t gfp_flags = low_order_gfp_flags;
>
> -		if (orders[i] > 4)
> +		if (orders[i] > PAGE_ALLOC_COSTLY_ORDER)
>   			gfp_flags = high_order_gfp_flags;
>   		pool = ion_page_pool_create(gfp_flags, orders[i]);
>   		if (!pool)
>

Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order

[Laura Abbott]

On 10/6/2014 3:27 AM, Heesub Shin wrote:
> Hello Kumar,
>
> On 10/06/2014 05:31 PM, Pintu Kumar wrote:
>> The Android ion_system_heap uses allocation fallback mechanism
>> based on 8,4,0 order pages available in the system.
>> It changes gfp flags based on higher order allocation request.
>> This higher order value is hard-coded as 4, instead of using
>> the system defined higher order value.
>> Thus replacing this hard-coded value with PAGE_ALLOC_COSTLY_ORDER
>> which is defined as 3.
>> This will help mapping the higher order request in system heap with
>> the actual allocation request.
>
> Quite reasonable.
>
> Reviewed-by: Heesub Shin <heesub.shin@samsung.com>
>
> BTW, Anyone knows how the allocation order (8,4 and 0) was decided? I
> think only Google guys might know the answer.
>
> regards,
> heesub
>

My understanding was this was completely unrelated to the costly order
and was related to the page sizes corresponding to IOMMU page sizes
(1MB, 64K, 4K). This won't make a difference for the uncached page
pool case but for the not page pool case, I'm not sure if there would
be a benefit for trying to get 32K pages with some effort vs. just
going back to 4K pages.

Do you have any data/metrics that show a benefit from this patch?

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation