lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 06 Oct 2014 16:26:15 +0000 (GMT)
From:	PINTU KUMAR <pintu.k@...sung.com>
To:	Laura Abbott <lauraa@...eaurora.org>,
	Heesub Shin <heesub.shin@...sung.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"john.stultz@...aro.org" <john.stultz@...aro.org>,
	"rebecca@...roid.com" <rebecca@...roid.com>,
	"ccross@...roid.com" <ccross@...roid.com>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:	IQBAL SHAREEF <iqbal.ams@...sung.com>,
	"pintu_agarwal@...oo.com" <pintu_agarwal@...oo.com>,
	Vishnu Pratap Singh <vishnu.ps@...sung.com>,
	"cpgs@...sung.com" <cpgs@...sung.com>
Subject: Re: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for
 high order

Hi,
>________________________________
> From: Laura Abbott <lauraa@...eaurora.org>
>To: Heesub Shin <heesub.shin@...sung.com>; Pintu Kumar <pintu.k@...sung.com>; akpm@...ux-foundation.org; gregkh@...uxfoundation.org; john.stultz@...aro.org; rebecca@...roid.com; ccross@...roid.com; devel@...verdev.osuosl.org; linux-kernel@...r.kernel.org 
>Cc: iqbal.ams@...sung.com; pintu_agarwal@...oo.com; vishnu.ps@...sung.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@...sung.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.

Powered by blists - more mailing lists