All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Shivank Garg" <shivankg@amd.com>
Cc: "Jeff Layton" <jlayton@kernel.org>,
	kvm@vger.kernel.org, "Chuck Lever" <cel@kernel.org>,
	dsterba@suse.cz, "Anna Schumaker" <anna@kernel.org>,
	damon@lists.linux.dev, linux-cxl@vger.kernel.org
Subject: Re: [PATCH RFC 05/11] mm/migrate: add a dedicated movable_ops migration pass
Date: Wed, 02 Sep 2026 11:04:12 +0000	[thread overview]
Message-ID: <20260902110412.BA5141F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902-migrate-refactor-shivank-v1-5-9dcca87669c4@amd.com>

> Pages with movable_ops transfer ownership through a driver callback and do
> not need the unmap, TLB flush, copy, or LRU handling used for LRU folios.
> These pages are expected to stop being represented as folios. Separating
> their migration from the LRU folio path prepares for that conversion.
> 
> Add migrate_movable_ops_pages() before LRU folio migration to handle
> allocation, locking, retries, and cleanup on a separate list. Return
> remaining pages through @ret_folios and remove the now-unreachable
> movable_ops branches from the LRU path.
> 
> This changes three details of movable_ops migration:
>  - Pages are processed before LRU folios rather than in source-list order.
>  - Synchronous callers use the requested mode from the first attempt
>    instead of the LRU asynchronous pre-pass.
>  - A callback returning -EAGAIN ends the current attempt, so a later
>    retry allocates a fresh destination.
>  - MIGRATE_SYNC_LIGHT waits for the page lock instead of giving up,
>    because !uptodate check is not applicable for movable_ops
>    pages.
> 
> Suggested-by: Zi Yan <ziy@nvidia.com>
> Suggested-by: David Hildenbrand (Arm) <david@kernel.org>
> Signed-off-by: Shivank Garg <shivankg@amd.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902-migrate-refactor-shivank-v1-0-9dcca87669c4@amd.com?part=5


  reply	other threads:[~2026-09-02 11:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 10:52 [PATCH RFC 00/11] mm/migrate: separate migration paths and carry migration policy Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 01/11] mm/migrate: extract folio unmap phase Shivank Garg
2026-09-02 11:02   ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 02/11] mm/migrate: handle retries in migrate_folios_move() Shivank Garg
2026-09-02 11:01   ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 03/11] mm/migrate: factor out folio splitting on allocation failure Shivank Garg
2026-09-02 11:06   ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 04/11] mm/migrate: use a dedicated list for hugetlb folios Shivank Garg
2026-09-02 11:02   ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 05/11] mm/migrate: add a dedicated movable_ops migration pass Shivank Garg
2026-09-02 11:04   ` sashiko-bot [this message]
2026-09-02 10:52 ` [PATCH RFC 06/11] mm/migrate: rename migrate_pages_batch() to migrate_folios_batch() Shivank Garg
2026-09-02 11:02   ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 07/11] mm/migrate: add migrate_lru_folios() entry point Shivank Garg
2026-09-02 11:03   ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 08/11] mm/migrate: move LRU batching into migrate_lru_folios() Shivank Garg
2026-09-02 11:00   ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 09/11] mm/migrate: thread migration policy through a control struct Shivank Garg
2026-09-02 11:06   ` sashiko-bot
2026-09-02 11:19   ` [sos-linux-ext-patches] " Garg, Shivank
2026-09-02 10:52 ` [PATCH RFC 10/11] mm/migrate: pass migrate_control to migrate_pages() Shivank Garg
2026-09-02 11:11   ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 11/11] mm/migrate: pass migrate_control to migrate_folio() Shivank Garg
2026-09-02 11:10   ` Jan Kara
2026-09-02 11:10   ` sashiko-bot

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=20260902110412.BA5141F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=anna@kernel.org \
    --cc=cel@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=dsterba@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=shivankg@amd.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 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.