linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: "Kirill A. Shutemov" <kirill@shutemov.name>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: [PATCH] compaction: fix isolate_migratepages_block() for THP=n
Date: Wed, 03 Jun 2015 11:14:05 +0200	[thread overview]
Message-ID: <556EC55D.40105@suse.cz> (raw)
In-Reply-To: <20150428224442.GA6188@node.dhcp.inet.fi>

On 04/29/2015 12:44 AM, Kirill A. Shutemov wrote:
>>>
>>> I wrote this to fix bug I originally attributed to refcounting patchset,
>>> but Sasha triggered the same bug on -next without the patchset applied:
>>>
>>> http://lkml.kernel.org/g/553EB993.7030401@oracle.com
>>
>> Well why the heck didn't the changelog tell us this?!?!?
> 
> Sasha reported bug in -next after I sent the patch.
> 
>>
>>> Now I think it's related to changing of PageLRU() behaviour on tail page
>>> by my page flags patchset.
>>
>> So this patch is a bugfix against one of
>>
>> page-flags-trivial-cleanup-for-pagetrans-helpers.patch
>> page-flags-introduce-page-flags-policies-wrt-compound-pages.patch
>> page-flags-define-pg_locked-behavior-on-compound-pages.patch
>> page-flags-define-behavior-of-fs-io-related-flags-on-compound-pages.patch
>> page-flags-define-behavior-of-lru-related-flags-on-compound-pages.patch
> 
> ^^^ this one is fault, I think.

So this patch is now:
http://www.ozlabs.org/~akpm/mmotm/broken-out/page-flags-define-behavior-of-lru-related-flags-on-compound-pages-fix.patch

I've found a non-fatal but misleading issues.

First, the "will fail to detect hugetlb pages in this case" part of the
changelog, and mention of hugetlbfs in the comment is AFAIK moot.
There's a PageLRU() check preceding the compound check, so hugetlbfs
pages (which are not PageLRU() AFAIK) are already skipped at that point.
I want to improve that in another series, but that's out of scope here.

Second, compound_order(page) returns 0 for a tail page, so the ALIGN()
trick that's supposed to properly advance pfn from a tail page is
useless. We could grab a head page, but stumbling on a THP tail page
should be very rare so it's not worth the trouble - just remove the ALIGN.

From: Vlastimil Babka <vbabka@suse.cz>
Date: Wed, 3 Jun 2015 11:03:37 +0200
Subject: [PATCH] page-flags-define-behavior-of-lru-related-flags-on-compound-pages-fix-fix

Mentioning hugetlbfs is misleading, because PageLRU() checks skip over hugetlb pages.
The ALIGN() parts are useless, because compound_order(page) returns 0 for tail pages.

---
 mm/compaction.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 6ef2fdf..16e1b57 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -733,9 +733,12 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
 		 * if PageLRU is set) but the lock is not necessarily taken
 		 * here and it is wasteful to take it just to check transhuge.
 		 * Check PageCompound without lock and skip the whole pageblock
-		 * if it's either a transhuge or hugetlbfs page, as calling
-		 * compound_order() without preventing THP from splitting the
-		 * page underneath us may return surprising results.
+		 * if it's a transhuge page, as calling compound_order()
+		 * without preventing THP from splitting the page underneath us
+		 * may return surprising results.
+		 * If we happen to check a THP tail page, compound_order()
+		 * returns 0. It should be rare enough to not bother with
+		 * using compound_head() in that case.
 		 */
 		if (PageCompound(page)) {
 			int nr;
@@ -743,7 +746,7 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
 				nr = 1 << compound_order(page);
 			else
 				nr = pageblock_nr_pages;
-			low_pfn = ALIGN(low_pfn + 1, nr) - 1;
+			low_pfn += nr - 1;
 			continue;
 		}
 
@@ -768,7 +771,7 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
 				continue;
 			if (PageCompound(page)) {
 				int nr = 1 << compound_order(page);
-				low_pfn = ALIGN(low_pfn + 1, nr) - 1;
+				low_pfn += nr - 1;
 				continue;
 			}
 		}
-- 
2.1.4


--
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:[~2015-06-03  9:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-27 11:26 Kirill A. Shutemov
2015-04-27 11:50 ` Vlastimil Babka
2015-04-28 22:14 ` Andrew Morton
2015-04-28 22:28   ` Kirill A. Shutemov
2015-04-28 22:37     ` Andrew Morton
2015-04-28 22:44       ` Kirill A. Shutemov
2015-06-03  9:14         ` Vlastimil Babka [this message]
2015-06-03 11:24           ` Kirill A. Shutemov

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=556EC55D.40105@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sasha.levin@oracle.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