LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Zi Yan <email@example.com> To: Hugh Dickins <firstname.lastname@example.org> Cc: Yang Shi <email@example.com>, "Kirill A. Shutemov" <firstname.lastname@example.org>, Matthew Wilcox <email@example.com>, Kent Overstreet <firstname.lastname@example.org>, Linux FS-devel Mailing List <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org>, Linux MM <email@example.com>, Johannes Weiner <firstname.lastname@example.org>, Linus Torvalds <email@example.com>, Andrew Morton <firstname.lastname@example.org>, "Darrick J. Wong" <email@example.com>, Christoph Hellwig <firstname.lastname@example.org>, David Howells <email@example.com>, Mike Kravetz <firstname.lastname@example.org> Subject: Re: Mapcount of subpages Date: Thu, 23 Sep 2021 20:25:39 -0400 [thread overview] Message-ID: <24B432CB-5CBB-4309-A9D0-6E1C4395A013@nvidia.com> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 2032 bytes --] 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 <firstname.lastname@example.org> 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 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 854 bytes --]
next prev parent reply other threads:[~2021-09-24 0:25 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-23 1:21 Struct page proposal Kent Overstreet 2021-09-23 3:23 ` Matthew Wilcox 2021-09-23 5:15 ` Kent Overstreet 2021-09-23 11:40 ` Mapcount of subpages Matthew Wilcox 2021-09-23 12:45 ` Kirill A. Shutemov 2021-09-23 21:10 ` Hugh Dickins 2021-09-23 21:54 ` Yang Shi 2021-09-23 22:23 ` Zi Yan 2021-09-23 23:48 ` Hugh Dickins 2021-09-24 0:25 ` Zi Yan [this message] 2021-09-24 0:57 ` Hugh Dickins 2021-09-24 1:11 ` Yang Shi 2021-09-24 1:31 ` Matthew Wilcox 2021-09-24 3:26 ` Yang Shi 2021-09-24 23:05 ` Kirill A. Shutemov 2021-09-23 18:56 ` Mike Kravetz 2021-09-23 9:03 ` Struct page proposal David Hildenbrand 2021-09-23 15:22 ` Kent Overstreet 2021-09-23 15:34 ` David Hildenbrand 2021-09-27 17:48 ` Vlastimil Babka 2021-09-27 17:53 ` Kent Overstreet 2021-09-27 18:34 ` Linus Torvalds 2021-09-27 20:45 ` David Hildenbrand 2021-09-27 18:05 ` Matthew Wilcox 2021-09-27 18:09 ` Kent Overstreet 2021-09-27 18:12 ` Matthew Wilcox 2021-09-27 18:16 ` David Hildenbrand 2021-09-27 18:53 ` Vlastimil Babka 2021-09-27 19:04 ` Linus Torvalds 2021-09-27 18:16 ` Kent Overstreet 2021-09-28 3:19 ` Matthew Wilcox 2021-09-27 19:07 ` Vlastimil Babka 2021-09-27 20:14 ` Kent Overstreet 2021-09-28 11:21 ` David Laight 2021-09-27 18:33 ` Kirill A. Shutemov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=24B432CB-5CBB-4309-A9D0-6E1C4395A013@nvidia.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).