On 23 Sep 2021, at 19:48, Hugh Dickins 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 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. > >> >> 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. You are right. unmap_page() during THP split is scanning the page tables already. For deciding whether to queue a THP for deferred split, we probably can keep PageDoubleMap bit to indicate if any subpage is PTE mapped. But without subpage _mapcount, detecting extra pins to a THP before split might be not as easy as with it. This means every THP split will need to perform unmap_page(), then check the remaining page_count to see if THP split is possible. That would also introduce extra system-wide overheads from unmapping pages. Am I missing anything? -- Best Regards, Yan, Zi