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

[Xishi Qiu <qiuxishi@huawei.com>]

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@gmail.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