All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Mel Gorman <mgorman@techsingularity.net>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH 1/3] mm, compaction: extend pageblock_skip_persistent() to all compound pages
Date: Fri, 3 Nov 2017 13:37:19 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1711031335350.29847@chino.kir.corp.google.com> (raw)
In-Reply-To: <20171102121706.21504-1-vbabka@suse.cz>

On Thu, 2 Nov 2017, Vlastimil Babka wrote:

> The pageblock_skip_persistent() function checks for HugeTLB pages of pageblock
> order. When clearing pageblock skip bits for compaction, the bits are not
> cleared for such pageblocks, because they cannot contain base pages suitable
> for migration, nor free pages to use as migration targets.
> 
> This optimization can be simply extended to all compound pages of order equal
> or larger than pageblock order, because migrating such pages (if they support
> it) cannot help sub-pageblock fragmentation. This includes THP's and also
> gigantic HugeTLB pages, which the current implementation doesn't persistently
> skip due to a strict pageblock_order equality check and not recognizing tail
> pages.
> 
> While THP pages are generally less "persistent" than HugeTLB, we can still
> expect that if a THP exists at the point of __reset_isolation_suitable(), it
> will exist also during the subsequent compaction run. The time difference here
> could be actually smaller than between a compaction run that sets a
> (non-persistent) skip bit on a THP, and the next compaction run that observes
> it.
> 
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>

This was originally done only for hugetlb because it was considered to be 
more persistent than thp, but with the presence of the deferred split 
shrinker I think this is fine.  It might be helpful to mention that the 
compound page is not synchronously split like it was prior to the thp 
refcounting patchset, however.

Acked-by: David Rientjes <rientjes@google.com>

WARNING: multiple messages have this Message-ID (diff)
From: David Rientjes <rientjes@google.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Mel Gorman <mgorman@techsingularity.net>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH 1/3] mm, compaction: extend pageblock_skip_persistent() to all compound pages
Date: Fri, 3 Nov 2017 13:37:19 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1711031335350.29847@chino.kir.corp.google.com> (raw)
In-Reply-To: <20171102121706.21504-1-vbabka@suse.cz>

On Thu, 2 Nov 2017, Vlastimil Babka wrote:

> The pageblock_skip_persistent() function checks for HugeTLB pages of pageblock
> order. When clearing pageblock skip bits for compaction, the bits are not
> cleared for such pageblocks, because they cannot contain base pages suitable
> for migration, nor free pages to use as migration targets.
> 
> This optimization can be simply extended to all compound pages of order equal
> or larger than pageblock order, because migrating such pages (if they support
> it) cannot help sub-pageblock fragmentation. This includes THP's and also
> gigantic HugeTLB pages, which the current implementation doesn't persistently
> skip due to a strict pageblock_order equality check and not recognizing tail
> pages.
> 
> While THP pages are generally less "persistent" than HugeTLB, we can still
> expect that if a THP exists at the point of __reset_isolation_suitable(), it
> will exist also during the subsequent compaction run. The time difference here
> could be actually smaller than between a compaction run that sets a
> (non-persistent) skip bit on a THP, and the next compaction run that observes
> it.
> 
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>

This was originally done only for hugetlb because it was considered to be 
more persistent than thp, but with the presence of the deferred split 
shrinker I think this is fine.  It might be helpful to mention that the 
compound page is not synchronously split like it was prior to the thp 
refcounting patchset, however.

Acked-by: David Rientjes <rientjes@google.com>

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

  parent reply	other threads:[~2017-11-03 20:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-02 12:17 [PATCH 1/3] mm, compaction: extend pageblock_skip_persistent() to all compound pages Vlastimil Babka
2017-11-02 12:17 ` Vlastimil Babka
2017-11-02 12:17 ` [PATCH 2/3] mm, compaction: split off flag for not updating skip hints Vlastimil Babka
2017-11-02 12:17   ` Vlastimil Babka
2017-11-02 13:09   ` Mel Gorman
2017-11-02 13:09     ` Mel Gorman
2017-11-02 12:17 ` [PATCH 3/3] mm, compaction: remove unneeded pageblock_skip_persistent() checks Vlastimil Babka
2017-11-02 12:17   ` Vlastimil Babka
2017-11-02 13:04 ` [PATCH 1/3] mm, compaction: extend pageblock_skip_persistent() to all compound pages Mel Gorman
2017-11-02 13:04   ` Mel Gorman
2017-11-03 20:37 ` David Rientjes [this message]
2017-11-03 20:37   ` David Rientjes

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=alpine.DEB.2.10.1711031335350.29847@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=vbabka@suse.cz \
    /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.