From: Longlong Xia <xialonglong@kylinos.cn>

Clean up KSM's scan helpers, advisor naming and sysfs formatting, then
pass folios through the merge path and update the related comments.

Patches 11-13 convert the merge targets of the merge path to folios,
continuing the earlier conversion of write_protect_page(),
stable_tree_insert() and the ksm_get_folio() helpers.

Before this series the merge path talked to the stable tree in folios
but to the merge helpers in pages, so the same ksm folio was wrapped
and unwrapped at every level:

  stable_tree_search() returns a folio
        |
        v
      try_to_merge_with_ksm_page(..., &kfolio->page)   <- unwrap
        |
        v
  try_to_merge_one_page(..., kpage)                    <- page all the way
        |
        v
  replace_page(vma, page, kpage, ...)
        |
        v
  kfolio = page_folio(kpage)                           <- re-wrap
  folio  = page_folio(page)                            <- re-wrap

With patches 11-13 every function in the chain takes the ksm folio
directly:

  stable_tree_search() returns a folio
        |
        v
      try_to_merge_with_ksm_folio(..., kfolio)
        |
        v
  try_to_merge_one_page(..., kfolio)
        |
        v
  replace_page(vma, folio, kfolio, ...)
        |
        v
  folio_page(folio, 0) only where a 4K page is needed (pte and rmap)

No functional change intended.

This series is based on next-20260914 (1a1de54f7369).

Longlong Xia (14):
  mm/ksm: constify ksm_next_page_ops
  mm/ksm: rename advisor_ctx to ksm_advisor_ctx
  mm/ksm: use the correct format specifier for max_page_sharing
  mm/ksm: add advance_scan_mm_slot() helper
  mm/ksm: make remove_stable_node_chain() return bool
  mm/ksm: clear all slab cache pointers in ksm_slab_free()
  mm/ksm: reuse the zero page pointer for merge tracing
  mm/ksm: document the two remove_rmap_item_from_tree() calls
  mm/ksm: move the no_vmas label out of the if block
  mm/ksm: extract ksm_begin_full_scan() from scan_get_next_rmap_item()
  mm/ksm: pass folios to replace_page()
  mm/ksm: take the ksm folio in try_to_merge_one_page()
  mm/ksm: take the ksm folio in try_to_merge_with_ksm_page()
  mm/ksm: update merge helper comments for folios

 mm/ksm.c | 270 +++++++++++++++++++++++++++++++------------------------
 1 file changed, 152 insertions(+), 118 deletions(-)

-- 
2.43.0

On Tue, Sep 15, 2026 at 11:12:14PM +0800, Longlong Xia wrote:
> From: Longlong Xia <xialonglong@kylinos.cn>
> 
> Clean up KSM's scan helpers, advisor naming and sysfs formatting, then
> pass folios through the merge path and update the related comments.

I'm not an expert in KSM, but it's not clear to me whether KSM should be
working in folios or pages.  That's why I stopped where I did, in the
hope that somebody with expertise would step in.  You have 17 commits
to Linux, one in KSM, so I'm not convinced you have relevant expertise.

Thanks for the review. You are right that I did not justify the
page/folio boundary clearly enough.

Patches 11-13 only avoid converting the target page back to a folio and
provide no functional or performance benefit by themselves.

I will separate the independent cleanups and drop or rework 11-13 after
getting guidance from the KSM maintainers. I also found a NULL/bisectability
issue in v1 patch 12, which I will fix before any follow-up.

Thanks,
Longlong

On 9/16/26 00:25, Longlong Xia wrote:
> Thanks for the review. You are right that I did not justify the
> page/folio boundary clearly enough.
> 
> Patches 11-13 only avoid converting the target page back to a folio and
> provide no functional or performance benefit by themselves.
> 
> I will separate the independent cleanups and drop or rework 11-13 after
> getting guidance from the KSM maintainers. I also found a NULL/bisectability
> issue in v1 patch 12, which I will fix before any follow-up.

In general: once we have a ksm folio (folio_test_ksm()), it can only be a small
folio and we can operate on the folio only.

Until that point, we really need the page, because we might be dealing with a
page in a large folio. Sure, we can carry a folio+page pair to reduce repeated
folio lookups, but be aware that we have to re-lookup the folio and take care of
references whenever we call into something that could end up splitting the
folio. So we have to be a bit careful around that.

-- 
Cheers,

David

On 2026/9/16 14:37, David Hildenbrand (Arm) wrote:
> On 9/16/26 00:25, Longlong Xia wrote:
>> Thanks for the review. You are right that I did not justify the
>> page/folio boundary clearly enough.
>>
>> Patches 11-13 only avoid converting the target page back to a folio and
>> provide no functional or performance benefit by themselves.
>>
>> I will separate the independent cleanups and drop or rework 11-13 after
>> getting guidance from the KSM maintainers. I also found a NULL/bisectability
>> issue in v1 patch 12, which I will fix before any follow-up.
> In general: once we have a ksm folio (folio_test_ksm()), it can only be a small
> folio and we can operate on the folio only.
>
> Until that point, we really need the page, because we might be dealing with a
> page in a large folio. Sure, we can carry a folio+page pair to reduce repeated
> folio lookups, but be aware that we have to re-lookup the folio and take care of
> references whenever we call into something that could end up splitting the
> folio. So we have to be a bit careful around that.

Hi David,

Thanks for the clarification. I understand that the page must be 
retained until we confirm it is a KSM folio.

I will drop patches 11–13 from this series and send a new version 
without them. Any reworked folio conversion patches will be sent 
separately later.

Best regards,
Longlong


>