LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Zi Yan <email@example.com> To: Yang Shi <firstname.lastname@example.org>, "Kirill A. Shutemov" <email@example.com> Cc: Hugh Dickins <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 18:23:32 -0400 [thread overview] Message-ID: <2A311B26-8B33-458E-B2C1-8BA2CF3484AA@nvidia.com> (raw) In-Reply-To: <CAHbLzkrELUKR2saOkA9_EeAyZwdboSq0HN6rhmCg2qxwSjdzbg@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 4604 bytes --] On 23 Sep 2021, at 17:54, Yang Shi wrote: > On Thu, Sep 23, 2021 at 2:10 PM Hugh Dickins <email@example.com> wrote: >> >> On Thu, 23 Sep 2021, Kirill A. Shutemov wrote: >>> On Thu, Sep 23, 2021 at 12:40:14PM +0100, Matthew Wilcox wrote: >>>> On Thu, Sep 23, 2021 at 01:15:16AM -0400, Kent Overstreet wrote: >>>>> On Thu, Sep 23, 2021 at 04:23:12AM +0100, Matthew Wilcox wrote: >>>>>> (compiling that list reminds me that we'll need to sort out mapcount >>>>>> on subpages when it comes time to do this. ask me if you don't know >>>>>> what i'm talking about here.) >>>>> >>>>> I am curious why we would ever need a mapcount for just part of a page, tell me >>>>> more. >>>> >>>> I would say Kirill is the expert here. My understanding: >>>> >>>> We have three different approaches to allocating 2MB pages today; >>>> anon THP, shmem THP and hugetlbfs. Hugetlbfs can only be mapped on a >>>> 2MB boundary, so it has no special handling of mapcount . Anon THP >>>> always starts out as being mapped exclusively on a 2MB boundary, but >>>> then it can be split by, eg, munmap(). If it is, then the mapcount in >>>> the head page is distributed to the subpages. >>> >>> One more complication for anon THP is that it can be shared across fork() >>> and one process may split it while other have it mapped with PMD. >>> >>>> Shmem THP is the tricky one. You might have a 2MB page in the page cache, >>>> but then have processes which only ever map part of it. Or you might >>>> have some processes mapping it with a 2MB entry and others mapping part >>>> or all of it with 4kB entries. And then someone truncates the file to >>>> midway through this page; we split it, and now we need to figure out what >>>> the mapcount should be on each of the subpages. We handle this by using >>>> ->mapcount on each subpage to record how many non-2MB mappings there are >>>> of that specific page and using ->compound_mapcount to record how many 2MB >>>> mappings there are of the entire 2MB page. Then, when we split, we just >>>> need to distribute the compound_mapcount to each page to make it correct. >>>> We also have the PageDoubleMap flag to tell us whether anybody has this >>>> 2MB page mapped with 4kB entries, so we can skip all the summing of 4kB >>>> mapcounts if nobody has done that. >>> >>> Possible future complication comes from 1G THP effort. With 1G THP we >>> would have whole hierarchy of mapcounts: 1 PUD mapcount, 512 PMD >>> mapcounts and 262144 PTE mapcounts. (That's one of the reasons I don't >>> think 1G THP is viable.) Maybe we do not need to support triple map. Instead, only allow PUD and PMD mappings and split 1GB THP to 2MB THPs before a PTE mapping is established. How likely is a 1GB THP going to be mapped by PUD and PTE entries? I guess it might be very rare. >>> >>> Note that there are places where exact mapcount accounting is critical: >>> try_to_unmap() may finish prematurely if we underestimate mapcount and >>> overestimating mapcount may lead to superfluous CoW that breaks GUP. >> >> It is critical to know for sure when a page has been completely unmapped: >> but that does not need ptes of subpages to be accounted in the _mapcount >> field of subpages - they just need to be counted in the compound page's >> total_mapcount. >> >> I may be wrong, I never had time to prove it one way or the other: but >> I have a growing suspicion that the *only* reason for maintaining tail >> _mapcounts separately, is to maintain the NR_FILE_MAPPED count exactly >> (in the face of pmd mappings overlapping pte mappings). >> >> 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. 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 you have a different point in mind when you refer to superfluous >> CoW and GUP: I don't know the score there (and I think we are still in >> that halfway zone, since pte CoW was changed to depend on page_count, >> but THP CoW still depending on mapcount). >> >> Hugh >> -- Best Regards, Yan, Zi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 854 bytes --]
next prev parent reply other threads:[~2021-09-23 22:23 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 [this message] 2021-09-23 23:48 ` Hugh Dickins 2021-09-24 0:25 ` Zi Yan 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=2A311B26-8B33-458E-B2C1-8BA2CF3484AA@nvidia.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 \ --email@example.com \ /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).