On Thu, 23 Sep 2021, Zi Yan wrote: > 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 <hughd@xxxxxxxxxx> 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. Maybe, maybe not. > > 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? I did not explain clearly enough: a subpage's ptes must still be counted in total_mapcount(); but I'm suggesting that perhaps they can be counted all together (either in the head page's _mapcount, or in a separate field if that works better), instead of being distributed amongst the separate subpages' _mapcounts. And this would lower the system-wide overheads inside total_mapcount() and page_mapped() (and maybe others). Hugh
