linux-kernel - Re: [RFC PATCH 2/2] mm/page_alloc: avoid splitting pages of order 2 and 3 in migration fallback

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56AC9371.5030605@huawei.com>
Date:	Sat, 30 Jan 2016 18:41:53 +0800
From:	Xishi Qiu <qiuxishi@...wei.com>
To:	ChengYi He <chengyihetaipei@...il.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...hsingularity.net>,
	Michal Hocko <mhocko@...e.com>,
	"Vlastimil Babka" <vbabka@...e.cz>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <js1304@...il.com>,
	Yaowei Bai <bywxiaobai@....com>,
	Alexander Duyck <alexander.h.duyck@...hat.com>,
	"'Kirill A . Shutemov'" <kirill.shutemov@...ux.intel.com>,
	Johannes Weiner <hannes@...xchg.org>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 2/2] mm/page_alloc: avoid splitting pages of order
 2 and 3 in migration fallback

On 2016/1/30 3:25, ChengYi He wrote:

> While buddy system fallbacks to allocate different migration type pages,
> it prefers the largest feasible pages and might split the chosen page
> into smalller ones. If the largest feasible pages are less than or equal
> to orde-3 and migration fallback happens frequently, then order-2 and
> order-3 pages can be exhausted easily. This patch aims to allocate the
> smallest feasible pages for the fallback mechanism under this condition.
> 
> Signed-off-by: ChengYi He <chengyihetaipei@...il.com>
> ---
>  mm/page_alloc.c | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 50c325a..3fcb653 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1802,9 +1802,22 @@ __rmqueue_fallback(struct zone *zone, unsigned int order, int start_migratetype)
>  	struct page *page;
>  
>  	/* Find the largest possible block of pages in the other list */
> -	for (current_order = MAX_ORDER-1;
> -				current_order >= order && current_order <= MAX_ORDER-1;
> -				--current_order) {
> +	for (current_order = MAX_ORDER - 1;
> +			current_order >= max_t(unsigned int, PAGE_ALLOC_COSTLY_ORDER + 1, order);
> +			--current_order) {
> +		page = __rmqueue_fallback_order(zone, order, start_migratetype,
> +				current_order);
> +
> +		if (page)
> +			return page;
> +	}
> +
> +	/*
> +	 * While current_order <= PAGE_ALLOC_COSTLY_ORDER, find the smallest
> +	 * feasible pages in the other list to avoid splitting high order pages
> +	 */
> +	for (current_order = order; current_order <= PAGE_ALLOC_COSTLY_ORDER;
> +			++current_order) {
>  		page = __rmqueue_fallback_order(zone, order, start_migratetype,
>  				current_order);
>  

Hi Chengyi,

So you mean use the largest block first, if no large block left, the use the
smallest block, right?

I have an idea, how about set two migrate types(movable and unmovable) when
doing init work? The function is memmap_init_zone().

I don't know how to set the ratio, maybe unmovable takes 1/10 memory, and left
9/10 memory to movable? I think this effect is a little like the two zones
(normal and movable). 

Another two ideas
https://lkml.org/lkml/2015/8/14/67
7d348b9ea64db0a315d777ce7d4b06697f946503, maybe this patch is not applied on your 3.10

Thanks,
Xishi Qiu