linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Zi Yan <zi.yan@sent.com>
To: Huang Ying <ying.huang@intel.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Zi Yan <ziy@nvidia.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	David Hildenbrand <david@redhat.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>
Subject: [PATCH 0/1] Large folio migration fix and questions on migration stats
Date: Mon,  9 Oct 2023 16:32:30 -0400	[thread overview]
Message-ID: <20231009203231.1715845-1-zi.yan@sent.com> (raw)

From: Zi Yan <ziy@nvidia.com>

I am adding support for >0 folio compaction and find the
VM_BUG_ON(!list_empty(&cc->migratepages)) in compact_zone() can be triggered
when a large folio is tried to be migrated, split, and its split base
pages are not migrated. The fix is in patch 1. In the upstream tree,
large folios can be migrated via move_pages() syscall and there is no
VM_BUG_ON in do_move_pages_to_node() but pages left in the source page
list will not be returned to LRU lists. This is from my code inspection
and I have not reproduced it on upstream tree yet.

In addition, I wonder if we need to add any large folio migration stats in
addition to existing THP migration stats, at least for large folio split
stats. Otherwise, large folio migrations seem to happen without any
notice.

Thanks.

Zi Yan (1):
  mm/migrate: correct nr_failed in migrate_pages_sync()

 mm/migrate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.42.0



             reply	other threads:[~2023-10-09 20:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-09 20:32 Zi Yan [this message]
2023-10-09 20:32 ` [PATCH 1/1] mm/migrate: correct nr_failed in migrate_pages_sync() Zi Yan
2023-10-10  3:36   ` Huang, Ying
2023-10-10 15:53     ` 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=20231009203231.1715845-1-zi.yan@sent.com \
    --to=zi.yan@sent.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.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