Re: [RFC PATCH 05/12] fs/proc/task_mmu: refactor pagemap_pmd_range()

[Lorenzo Stoakes]

On Mon, Oct 27, 2025 at 05:31:54PM +0100, David Hildenbrand wrote:
> >
> > I don't love the union.
> >
> > How would we determine what type it is, we'd have to have some
> > generic_leaf_entry_t type or something to contain the swap type field and then
> > cast and... is it worth it?
> >
> > Intent of non-present was to refer to not-swap swapentry. It's already a
> > convention that exists, e.g. is_pmd_non_present_folio_entry().
>
> Just noting that this was a recent addition (still not upstream) that
> essentially says "there is a folio here, but it's not in an ordinary present
> page table entry.
>
> So we could change that to something better.

Yeah but leaf_entry_t encapsulates BOTH swap and non-swap entries.

So that's nice.

What do you propose calling non-swap leaf entries? It starts spiralling down a
bit there.

And it's really common to have logic asserting it's actually a swap entry
vs. not etc.

I think we need to separate out what's practical for this series and what's
ideal going forwards.

Right now it's a complete mess, I don't want this to turn into a talking shop
that bogs things down so we don't move forward because it doesn't address
everything all at once.

What we have here already improves things dramatically IMO.

So what I propose is:

1. we keep the non-present terminology as a better way of referring to non-swap
   entries.

2. When I come to do the leaf_entry_t series, we can generalise and no longer
   differentiate between swap + non-swap.

We can then resume the discussion re: type there.

>
> --
> Cheers
>
> David / dhildenb
>

THanks, Lorenzo