All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xishi Qiu <qiuxishi@huawei.com>
To: Mel Gorman <mgorman@techsingularity.net>,
	Michal Hocko <mhocko@suse.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Vlastimil Babka <vbabka@suse.cz>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	Yisheng Xie <xieyisheng1@huawei.com>
Subject: [RFC] mm: a question about high-order check in __zone_watermark_ok()
Date: Mon, 26 Sep 2016 16:47:57 +0800	[thread overview]
Message-ID: <57E8E0BD.2070603@huawei.com> (raw)

commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1
(mm, page_alloc: only enforce watermarks for order-0 allocations)
rewrite the high-order check in __zone_watermark_ok(), but I think it
quietly fix a bug. Please see the following.

Before this patch, the high-order check is this:
__zone_watermark_ok()
	...
	for (o = 0; o < order; o++) {
		/* At the next order, this order's pages become unavailable */
		free_pages -= z->free_area[o].nr_free << o;

		/* Require fewer higher order pages to be free */
		min >>= 1;

		if (free_pages <= min)
			return false;
	}
	...

If we have cma memory, and we alloc a high-order movable page, then it's right.

But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()),
and there are a lot of high-order cma pages, but little high-order unmovable
pages, the it is still return *true*, but we will alloc *failed* finally, because
we cannot fallback from migrate_unmovable to migrate_cma, right?

Also if we doing __alloc_pages_slowpath(), the compact will not work, because
__zone_watermark_ok() always return true, and it lead to alloc a high-order
unmovable page failed, then do direct reclaim.

Thanks,
Xishi Qiu

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com>
To: Mel Gorman <mgorman@techsingularity.net>,
	Michal Hocko <mhocko@suse.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Vlastimil Babka <vbabka@suse.cz>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	Yisheng Xie <xieyisheng1@huawei.com>
Subject: [RFC] mm: a question about high-order check in __zone_watermark_ok()
Date: Mon, 26 Sep 2016 16:47:57 +0800	[thread overview]
Message-ID: <57E8E0BD.2070603@huawei.com> (raw)

commit 97a16fc82a7c5b0cfce95c05dfb9561e306ca1b1
(mm, page_alloc: only enforce watermarks for order-0 allocations)
rewrite the high-order check in __zone_watermark_ok(), but I think it
quietly fix a bug. Please see the following.

Before this patch, the high-order check is this:
__zone_watermark_ok()
	...
	for (o = 0; o < order; o++) {
		/* At the next order, this order's pages become unavailable */
		free_pages -= z->free_area[o].nr_free << o;

		/* Require fewer higher order pages to be free */
		min >>= 1;

		if (free_pages <= min)
			return false;
	}
	...

If we have cma memory, and we alloc a high-order movable page, then it's right.

But if we alloc a high-order unmovable page(e.g. alloc kernel stack in dup_task_struct()),
and there are a lot of high-order cma pages, but little high-order unmovable
pages, the it is still return *true*, but we will alloc *failed* finally, because
we cannot fallback from migrate_unmovable to migrate_cma, right?

Also if we doing __alloc_pages_slowpath(), the compact will not work, because
__zone_watermark_ok() always return true, and it lead to alloc a high-order
unmovable page failed, then do direct reclaim.

Thanks,
Xishi Qiu

             reply	other threads:[~2016-09-26  8:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-26  8:47 Xishi Qiu [this message]
2016-09-26  8:47 ` [RFC] mm: a question about high-order check in __zone_watermark_ok() Xishi Qiu
2016-09-26  8:52 ` Vlastimil Babka
2016-09-26  8:52   ` Vlastimil Babka
2016-09-26  8:58 ` Michal Hocko
2016-09-26  8:58   ` Michal Hocko
2016-09-26  9:16   ` Xishi Qiu
2016-09-26  9:16     ` Xishi Qiu
2016-09-26  9:43     ` Michal Hocko
2016-09-26  9:43       ` Michal Hocko
2016-09-26 10:17       ` Xishi Qiu
2016-09-26 10:17         ` Xishi Qiu
2016-09-26 11:02         ` Michal Hocko
2016-09-26 11:02           ` Michal Hocko
2016-09-28  5:52           ` Joonsoo Kim
2016-09-28  5:52             ` Joonsoo Kim
2016-09-28  7:54             ` Xishi Qiu
2016-09-28  7:54               ` Xishi Qiu

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=57E8E0BD.2070603@huawei.com \
    --to=qiuxishi@huawei.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=vbabka@suse.cz \
    --cc=xieyisheng1@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.