From: Pedro Falcato <pfalcato@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>, Zi Yan <ziy@nvidia.com>
Cc: Pedro Falcato <pfalcato@suse.de>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <liam@infradead.org>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Lorenzo Stoakes <ljs@kernel.org>,
Kiryl Shutsemau <kas@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/8] mm/khugepaged: collapse_file() cleanups
Date: Wed, 11 Nov 2026 17:51:13 +0000 [thread overview]
Message-ID: <20261111175121.1328383-1-pfalcato@suse.de> (raw)
Here are a bunch of cleanups for collapse_file() that attempt to aid
code readability and understanding. This is part 1 out of N, and only
attempts to address the main collapse loop. The exit path is still a
mess but I figure it's much easier to review if I send this batch as-is,
versus sending the whole thing.
Tested using the khugepaged shmem and file selftests.
Based on top of latest mm-core/for-next.
Note that some review comments from v1 went unaddressed
(Nico's larger restructuring, some small Lorenzo suggestions) for a couple
of small reasons. The main one being that I want to get this v2 out before
going insane :)) I agreed to work with Nico, and I'll either send out some
of his patches as a followup, or he will.
In any case, I'm tired of this function and I hope this kicks off some
discussion :)
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: "Liam R. Howlett" <liam@infradead.org>
Cc: Nico Pache <nico.pache@linux.dev>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Dev Jain <dev.jain@arm.com>
Cc: Barry Song <baohua@kernel.org>
Cc: Lance Yang <lance.yang@linux.dev>
Cc: Usama Arif <usama.arif@linux.dev>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Kiryl Shutsemau <kas@kernel.org>
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Changes in v2:
- Rebased on current mm-core/for-next, which contains a number of fixes to
the amazingly simple and awesome collapse_file() function.
- Fix the "bad unlock balance" reported by syzbot ci (syzbot ci, Lorenzo)
- 1/8:
- Fold in v1 5/8 (kerneldoc); new helpers get their kerneldoc in
the patch that introduces them. (Lorenzo)
- Group the input fields of collapse_file_state and make end and
is_shmem const; is_shmem is now a bool. (Lorenzo)
- Wrap the prepare_collapse_file_folio() declaration to fit in 80
columns. (Lorenzo)
- Keep the original LRU drain behaviour (drain only after a
successful shmem_get_folio()) (Lorenzo)
- 2/8: New patch. Turn value entries into NULL before calling
prepare_collapse_file_folio().
- 3/8 (v1 2/8):
- Rename collapse_read_folio() to maybe_read_folio(). (Lorenzo)
- Replace the compound condition with an early-return guard.
(Lorenzo)
- Comment on why the xa_lock is dropped. (Lorenzo)
- Expand the commit message. (Lorenzo)
- 5/8 (v1 4/8): Drop a duplicate blank line.
- 6/8: Add a commit message, noting that errors before try_to_unmap()
no longer call try_to_unmap_flush() themselves.
- 7/8: Explain in the commit message why the refcount and dirty checks
don't need the i_pages lock. The flush added by 854e5ff8b3ce now
happens at out_putback.
- 8/8: Retitle (drop "fix"), since 854e5ff8b3ce already reworded the
comment; drop a stray blank line.
Link to v1: https://lore.kernel.org/all/20260720142913.846902-1-pfalcato@suse.de/
Pedro Falcato (8):
mm/khugepaged: separate out windy folio logic from collapse_file
mm/khugepaged: sanitize the folio passed to file folio collapse logic
mm/khugepaged: factor out page cache folio reading
mm/khugepaged: factor out and simplify dirty/writeback handling
mm/khugepaged: simplify prepare folio locking and exit paths
mm/khugepaged: hoist isolation into collapse_isolate_folio()
mm/khugepaged: hoist more code into collapse_isolate_folio()
mm/khugepaged: flesh out try_to_unmap_flush() comment
mm/khugepaged.c | 461 ++++++++++++++++++++++++++++++------------------
1 file changed, 286 insertions(+), 175 deletions(-)
base-commit: 8d21e3d3faf19f461f6d0380fe8a1f5bdba97f25
--
2.56.0
next reply other threads:[~2026-11-11 17:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 17:51 Pedro Falcato [this message]
2026-11-11 17:51 ` [PATCH v2 1/8] mm/khugepaged: separate out windy folio logic from collapse_file Pedro Falcato
2026-11-11 17:51 ` [PATCH v2 2/8] mm/khugepaged: sanitize the folio passed to file folio collapse logic Pedro Falcato
2026-11-11 17:51 ` [PATCH v2 3/8] mm/khugepaged: factor out page cache folio reading Pedro Falcato
2026-11-11 17:51 ` [PATCH v2 4/8] mm/khugepaged: factor out and simplify dirty/writeback handling Pedro Falcato
2026-11-11 17:51 ` [PATCH v2 5/8] mm/khugepaged: simplify prepare folio locking and exit paths Pedro Falcato
2026-11-11 17:51 ` [PATCH v2 6/8] mm/khugepaged: hoist isolation into collapse_isolate_folio() Pedro Falcato
2026-11-11 17:51 ` [PATCH v2 7/8] mm/khugepaged: hoist more code " Pedro Falcato
2026-11-11 17:51 ` [PATCH v2 8/8] mm/khugepaged: flesh out try_to_unmap_flush() comment Pedro Falcato
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=20261111175121.1328383-1-pfalcato@suse.de \
--to=pfalcato@suse.de \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=nico.pache@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=usama.arif@linux.dev \
--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
all inboxes | Powered by JetHome®