linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Skidanov <alexey.skidanov@intel.com>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
	Alexey Skidanov <alexey.skidanov@intel.com>
Subject: [PATCH] mm: Free CMA pages to the buddy allocator instead of per-cpu-pagelists
Date: Thu,  8 Feb 2018 23:21:53 +0200	[thread overview]
Message-ID: <1518124913-31290-1-git-send-email-alexey.skidanov@intel.com> (raw)

The current code frees pages to the per-cpu-pagelists (pcp) according to
their migrate type. The exception is isolated pages that are freed
directly to the buddy allocator.

The pages are marked as isolate to indicate the buddy allocator that
they are not supposed to be allocated as opposite to the pages located
in the pcp lists that are immediate candidates for the upcoming
allocation requests.

This was likely an oversight when the CMA migrate type was added. As a
result of this, freed CMA pages go to the MIGRATE_MOVABLE per-cpu-list.
This sometime leads to CMA page allocation instead of Movable one,
increasing the probability of CMA page pining, which may cause to CMA
allocation failure. In addition, there is no gain to free CMA page to
the pcp because the CMA pages mainly allocated for DMA purpose.

To fix this, we free CMA page directly to the buddy allocator. This
avoids the CMA page allocation instead of MOVABLE one. Actually, the CMA
pages are very similar to the isolated ones - both of them should not be
supposed as immediate candidates for upcoming allocation requests and
thus shouldn't be freed to pcp. I've audited all the other checks for
isolated pageblocks to ensure that this mistake was not repeated elsewhere.

Signed-off-by: Alexey Skidanov <alexey.skidanov@intel.com>
---
 mm/page_alloc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 59d5921..9a76b68 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2644,7 +2644,8 @@ static void free_unref_page_commit(struct page *page, unsigned long pfn)
 	 * excessively into the page allocator
 	 */
 	if (migratetype >= MIGRATE_PCPTYPES) {
-		if (unlikely(is_migrate_isolate(migratetype))) {
+		if (unlikely(is_migrate_isolate(migratetype) ||
+				is_migrate_cma(migratetype))) {
 			free_one_page(zone, page, pfn, 0, migratetype);
 			return;
 		}
-- 
2.7.4

                 reply	other threads:[~2018-02-08 21:21 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1518124913-31290-1-git-send-email-alexey.skidanov@intel.com \
    --to=alexey.skidanov@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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;
as well as URLs for NNTP newsgroup(s).