Re: [PATCH v2 3/3] mm: move reclaim-internal declarations out of swap.h

[Jianyue Wu]

On Mon, Jun 1, 2026 at 10:57 PM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> Skimming over this, what a confusing function name (having free_pages() etc in
> mind). In particular, that it's interesting in a single high-order page judging
> from the interface?
>
> I wonder if making it clearer that this is a direct reclaim interface would
> improve the situation.
>
> "direct_reclaim_...()"
>
> Similar for try_to_free_mem_cgroup_pages -- which actually consumes nr_pages.
>
> Just a random thought ...
>
> Moving a lot of stuff out of swap.h sounds like a good idea. I do wonder if
> mm/internal.h should be split up as well (to minimize future conflicts).
>
> --
> Cheers,
>
> David

Hi David,

Thanks for the review.

Good catch on MAINTAINERS — I missed that in v2. I've updated it locally:
- MGLRU: F: mm/swap.c -> F: mm/folio_lru.c
- SWAP: drop the stale F: mm/swap.c entry (swap code is already
  covered by swap_state.c, page_io.c, swapfile.c, etc.)
- Docs: update the remaining mm/swap.c references in
  Documentation/admin-guide/sysctl/vm.rst and
  Documentation/core-api/mm-api.rst
I'll include those in v3.

On try_to_free_pages() / try_to_free_mem_cgroup_pages() naming:
agree the names are misleading next to free_pages() -- they trigger
reclaim, not free owned pages. The order argument reflects the
allocation request that triggered direct reclaim, not "free one
high-order page".

I had a quick look: try_to_free_pages() is only called from
__perform_reclaim() in page_alloc.c (plus a comment in fuse/file.c),
so renaming that entry point would be a small follow-up -- something
like direct_reclaim_pages() for the page-alloc path. I'll keep the
existing names in v3 to avoid expanding scope; try_to_free_mem_cgroup_pages()
has more call sites and I'd treat them separately.

Thanks,
Jianyue