Date: Mon, 06 Oct 2014 16:26:15 +0000 (GMT)
From: PINTU KUMAR <pintu.k@samsung.com>
Subject: Re: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for
 high order
To: Laura Abbott <lauraa@codeaurora.org>,
        Heesub Shin <heesub.shin@samsung.com>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "john.stultz@linaro.org" <john.stultz@linaro.org>,
        "rebecca@android.com" <rebecca@android.com>,
        "ccross@android.com" <ccross@android.com>,
        "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: IQBAL SHAREEF <iqbal.ams@samsung.com>,
        "pintu_agarwal@yahoo.com" <pintu_agarwal@yahoo.com>,
        Vishnu Pratap Singh <vishnu.ps@samsung.com>,
        "cpgs@samsung.com" <cpgs@samsung.com>
Reply-to: pintu.k@samsung.com
MIME-version: 1.0
Msgkey: 20141006153958031@pintu.k
Content-type: text/plain; charset=windows-1252
MIME-version: 1.0
Message-id: <1689163249.303621412612771982.JavaMail.weblogic@epmlwas07b>
DLP-Filter: Pass
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit

Hi,
>________________________________
> From: Laura Abbott <lauraa@codeaurora.org>
>To: Heesub Shin <heesub.shin@samsung.com>; Pintu Kumar <pintu.k@samsung.com>; akpm@linux-foundation.org; gregkh@linuxfoundation.org; john.stultz@linaro.org; rebecca@android.com; ccross@android.com; devel@driverdev.osuosl.org; linux-kernel@vger.kernel.org 
>Cc: iqbal.ams@samsung.com; pintu_agarwal@yahoo.com; vishnu.ps@samsung.com 
>Sent: Monday, 6 October 2014 7:37 PM
>Subject: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order
> 
>
>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.

No, it is not just related to IOMMU case. It comes into picture also for 
normal system-heap allocation (without iommu cases).
Also, it is applicable for both uncached and page_pool cases.
Please also check the changes under ion_system_heap_create.
Here the gfp_flags are set under the pool structure.
This value is used in ion_page_pool_alloc_pages.
In both the cases, it internally calls alloc_pages, with this gfp_flags.
Now, during memory pressure scenario, when alloc_pages moves to slowpath 
this gfp_flags will be used to decide allocation retry.
In the current code, the higher-order flag is set only when order is greater than 4.
But, in MM, the order 4 is also considered as higher-order request. 
This higher-order is decided based on PAGE_ALLOC_COSTLY_ORDER (3) value.
Hence, I think this value should be in sync with the MM code.

>
>Do you have any data/metrics that show a benefit from this patch?
I think it is not related to any data or metrics.
It is about replacing the hard-coded higher-order check to be in sync with 
the MM code.

????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?