linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Hui Zhu <zhuhui@xiaomi.com>
Cc: akpm@linux-foundation.org, vbabka@suse.cz,
	mgorman@techsingularity.net, hillf.zj@alibaba-inc.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	teawater@gmail.com
Subject: Re: [RFC 1/2] Try to use HighAtomic if try to alloc umovable page that order is not 0
Date: Tue, 26 Sep 2017 12:47:52 +0200	[thread overview]
Message-ID: <20170926104752.e5jyygwyqhqqvmjl@dhcp22.suse.cz> (raw)
In-Reply-To: <1506415604-4310-2-git-send-email-zhuhui@xiaomi.com>

On Tue 26-09-17 16:46:43, Hui Zhu wrote:
> The page add a new condition to let gfp_to_alloc_flags return
> alloc_flags with ALLOC_HARDER if the order is not 0 and migratetype is
> MIGRATE_UNMOVABLE.

Apart from what Mel has already said this changelog is really lacking
the crucial information. It says what but it doesn't explain why we need
this and why it is safe to do. What kind of workload will benefit from
this change and how much. What about those users who are relying on high
atomic reserves currently and now would need to share it with other
users.

Without knowing all that background and from a quick look this looks
like a very crude hack to me, to be completely honest.

> Then alloc umovable page that order is not 0 will try to use HighAtomic.
> 
> Signed-off-by: Hui Zhu <zhuhui@xiaomi.com>
> ---
>  mm/page_alloc.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c841af8..b54e94a 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3642,7 +3642,7 @@ static void wake_all_kswapds(unsigned int order, const struct alloc_context *ac)
>  }
>  
>  static inline unsigned int
> -gfp_to_alloc_flags(gfp_t gfp_mask)
> +gfp_to_alloc_flags(gfp_t gfp_mask, int order, int migratetype)
>  {
>  	unsigned int alloc_flags = ALLOC_WMARK_MIN | ALLOC_CPUSET;
>  
> @@ -3671,6 +3671,8 @@ static void wake_all_kswapds(unsigned int order, const struct alloc_context *ac)
>  		alloc_flags &= ~ALLOC_CPUSET;
>  	} else if (unlikely(rt_task(current)) && !in_interrupt())
>  		alloc_flags |= ALLOC_HARDER;
> +	else if (order > 0 && migratetype == MIGRATE_UNMOVABLE)
> +		alloc_flags |= ALLOC_HARDER;
>  
>  #ifdef CONFIG_CMA
>  	if (gfpflags_to_migratetype(gfp_mask) == MIGRATE_MOVABLE)
> @@ -3903,7 +3905,7 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
>  	 * kswapd needs to be woken up, and to avoid the cost of setting up
>  	 * alloc_flags precisely. So we do that now.
>  	 */
> -	alloc_flags = gfp_to_alloc_flags(gfp_mask);
> +	alloc_flags = gfp_to_alloc_flags(gfp_mask, order, ac->migratetype);
>  
>  	/*
>  	 * We need to recalculate the starting point for the zonelist iterator
> -- 
> 1.9.1
> 

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-09-26 10:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-26  8:46 [RFC 0/2] Use HighAtomic against long-term fragmentation Hui Zhu
2017-09-26  8:46 ` [RFC 1/2] Try to use HighAtomic if try to alloc umovable page that order is not 0 Hui Zhu
2017-09-26 10:47   ` Michal Hocko [this message]
2017-09-26  8:46 ` [RFC 2/2] Change limit of HighAtomic from 1% to 10% Hui Zhu
2017-09-26  9:51 ` [RFC 0/2] Use HighAtomic against long-term fragmentation Mel Gorman
2017-09-26 10:04   ` Hui Zhu
2017-09-26 10:43     ` Mel Gorman

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=20170926104752.e5jyygwyqhqqvmjl@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hillf.zj@alibaba-inc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=teawater@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=zhuhui@xiaomi.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