From: PINTU KUMAR <pintu.k@samsung.com>
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>
Subject: Re: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order
Date: Mon, 06 Oct 2014 16:26:15 +0000 (GMT) [thread overview]
Message-ID: <1689163249.303621412612771982.JavaMail.weblogic@epmlwas07b> (raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252, Size: 2987 bytes --]
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Ç+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
next reply other threads:[~2014-10-06 16:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-06 16:26 PINTU KUMAR [this message]
2014-10-06 17:31 ` Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order Colin Cross
2014-10-07 16:07 ` PINTU KUMAR
2014-10-07 16:19 ` Colin Cross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1689163249.303621412612771982.JavaMail.weblogic@epmlwas07b \
--to=pintu.k@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=ccross@android.com \
--cc=cpgs@samsung.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=heesub.shin@samsung.com \
--cc=iqbal.ams@samsung.com \
--cc=john.stultz@linaro.org \
--cc=lauraa@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pintu_agarwal@yahoo.com \
--cc=rebecca@android.com \
--cc=vishnu.ps@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).