Re: Mapcount of subpages

[Yang Shi <shy828301@gmail.com>]

On Thu, Sep 23, 2021 at 4:49 PM Hugh Dickins <hughd@google.com> wrote:
>
> On Thu, 23 Sep 2021, Zi Yan wrote:
> > On 23 Sep 2021, at 17:54, Yang Shi wrote:
> > > On Thu, Sep 23, 2021 at 2:10 PM Hugh Dickins <hughd@google.com> wrote:
> > >>
> > >> NR_FILE_MAPPED being used for /proc/meminfo's "Mapped:" and a couple
> > >> of other such stats files, and for a reclaim heuristic in mm/vmscan.c.
> > >>
> > >> Allow ourselves more slack in NR_FILE_MAPPED accounting (either count
> > >> each pte as if it mapped the whole THP, or don't count a THP's ptes
> > >> at all - you opted for the latter in the "Mlocked:" accounting),
> > >> and I suspect subpage _mapcount could be abandoned.
> > >
> > > AFAIK, partial THP unmap may need the _mapcount information of every
> > > subpage otherwise the deferred split can't know what subpages could be
> > > freed.
>
> I believe Yang Shi is right insofar as the decision on whether it's worth
> queuing for deferred split is being done based on those subpage _mapcounts.
> That is a use I had not considered, and I've given no thought to how
> important or not it is.

Anyway deferred split is anon THP specific. We don't have to worry
about this for file THP. So your suggestion about just counting total
mapcount seems feasible to me for file THP at least.

>
> >
> > Could we just scan page tables of a THP during deferred split process
> > instead? Deferred split is a slow path already, so maybe it can afford
> > the extra work.
>
> But unless I misunderstand, actually carrying out the deferred split
> already unmaps, uses migration entries, and remaps the remaining ptes:
> needing no help from subpage _mapcounts to do those, and free the rest.
>
> Hugh