linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Zi Yan <zi.yan@sent.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Zi Yan <ziy@nvidia.com>, Ryan Roberts <ryan.roberts@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	David Hildenbrand <david@redhat.com>,
	"Yin, Fengwei" <fengwei.yin@intel.com>,
	Yu Zhao <yuzhao@google.com>, Vlastimil Babka <vbabka@suse.cz>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Kemeng Shi <shikemeng@huaweicloud.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Rohan Puri <rohan.puri15@gmail.com>,
	Mcgrof Chamberlain <mcgrof@kernel.org>,
	Adam Manzanares <a.manzanares@samsung.com>,
	John Hubbard <jhubbard@nvidia.com>
Subject: Re: [RFC PATCH 3/4] mm/compaction: optimize >0 order folio compaction by sorting source pages.
Date: Tue, 12 Sep 2023 13:56:10 -0400	[thread overview]
Message-ID: <20230912175610.GC34089@cmpxchg.org> (raw)
In-Reply-To: <20230912162815.440749-4-zi.yan@sent.com>

On Tue, Sep 12, 2023 at 12:28:14PM -0400, Zi Yan wrote:
> From: Zi Yan <ziy@nvidia.com>
> 
> It should maximize high order free page use and minimize free page splits.
> It might be useful before free page merging is implemented.

The premise sounds reasonable to me: start with the largest chunks in
the hope of producing the desired block size before having to piece
things together from the order-0s dribbles.

> @@ -145,6 +145,38 @@ static void sort_free_pages(struct list_head *src, struct free_list *dst)
>  	}
>  }
>  
> +static void sort_folios_by_order(struct list_head *pages)
> +{
> +	struct free_list page_list[MAX_ORDER + 1];
> +	int order;
> +	struct folio *folio, *next;
> +
> +	for (order = 0; order <= MAX_ORDER; order++) {
> +		INIT_LIST_HEAD(&page_list[order].pages);
> +		page_list[order].nr_free = 0;
> +	}
> +
> +	list_for_each_entry_safe(folio, next, pages, lru) {
> +		order = folio_order(folio);
> +
> +		if (order > MAX_ORDER)
> +			continue;
> +
> +		list_move(&folio->lru, &page_list[order].pages);
> +		page_list[order].nr_free++;
> +	}
> +
> +	for (order = MAX_ORDER; order >= 0; order--) {
> +		if (page_list[order].nr_free) {
> +
> +			list_for_each_entry_safe(folio, next,
> +						 &page_list[order].pages, lru) {
> +				list_move_tail(&folio->lru, pages);
> +			}
> +		}
> +	}
> +}
> +
>  #ifdef CONFIG_COMPACTION
>  bool PageMovable(struct page *page)
>  {
> @@ -2636,6 +2668,8 @@ compact_zone(struct compact_control *cc, struct capture_control *capc)
>  				pageblock_start_pfn(cc->migrate_pfn - 1));
>  		}
>  
> +		sort_folios_by_order(&cc->migratepages);

Would it make sense to have isolate_migratepages_block() produce a
sorted list already? By collecting into a struct free_list in there
and finishing with that `for (order = MAX...) list_add_tail()' loop.

That would save quite a bit of shuffling around. Compaction can be
hot, and is expected to get hotter with growing larger order pressure.

The contig allocator doesn't care about ordering, but it should be
possible to gate the sorting reasonably on !cc->alloc_contig.

An optimization down the line could be to skip the sorted list
assembly for the compaction case entirely, have compact_zone() work
directly on struct free_list, starting with the highest order and
checking compact_finished() in between orders.


  reply	other threads:[~2023-09-12 17:56 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12 16:28 [RFC PATCH 0/4] Enable >0 order folio memory compaction Zi Yan
2023-09-12 16:28 ` [RFC PATCH 1/4] mm/compaction: add support for " Zi Yan
2023-09-12 17:32   ` Johannes Weiner
2023-09-12 17:38     ` Zi Yan
2023-09-15  9:33   ` Baolin Wang
2023-09-18 17:06     ` Zi Yan
2023-10-10  8:07   ` Huang, Ying
2023-09-12 16:28 ` [RFC PATCH 2/4] mm/compaction: optimize >0 order folio compaction with free page split Zi Yan
2023-09-18  7:34   ` Baolin Wang
2023-09-18 17:20     ` Zi Yan
2023-09-20  8:15       ` Baolin Wang
2023-09-12 16:28 ` [RFC PATCH 3/4] mm/compaction: optimize >0 order folio compaction by sorting source pages Zi Yan
2023-09-12 17:56   ` Johannes Weiner [this message]
2023-09-12 20:31     ` Zi Yan
2023-09-12 16:28 ` [RFC PATCH 4/4] mm/compaction: enable compacting >0 order folios Zi Yan
2023-09-15  9:41   ` Baolin Wang
2023-09-18 17:17     ` Zi Yan
2023-09-20 14:44   ` kernel test robot
2023-09-21  0:55 ` [RFC PATCH 0/4] Enable >0 order folio memory compaction Luis Chamberlain
2023-09-21  1:16   ` Luis Chamberlain
2023-09-21  2:05     ` John Hubbard
2023-09-21  3:14       ` Luis Chamberlain
2023-09-21 15:56         ` Zi Yan
2023-10-02 12:32 ` Ryan Roberts
2023-10-09 13:24   ` Zi Yan
2023-10-09 14:10     ` Ryan Roberts
2023-10-09 15:42       ` Zi Yan
2023-10-09 15:52       ` Zi Yan
2023-10-10 10:00         ` Ryan Roberts
2023-10-09  7:12 ` Huang, Ying
2023-10-09 13:43   ` Zi Yan
2023-10-10  6:08     ` Huang, Ying
2023-10-10 16:48       ` Zi Yan

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=20230912175610.GC34089@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=a.manzanares@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@redhat.com \
    --cc=fengwei.yin@intel.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcgrof@kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=rohan.puri15@gmail.com \
    --cc=ryan.roberts@arm.com \
    --cc=shikemeng@huaweicloud.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.com \
    --cc=zi.yan@sent.com \
    --cc=ziy@nvidia.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