From: Peter Collingbourne <pcc@google.com> To: Catalin Marinas <catalin.marinas@arm.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name>, Andrew Morton <akpm@linux-foundation.org>, Evgenii Stepanov <eugenis@google.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>, linux-mm@kvack.org Subject: Re: [PATCH] mm: introduce reference pages Date: Mon, 3 Aug 2020 17:50:32 -0700 [thread overview] Message-ID: <CAMn1gO54gTG5f1dVfZHAaXWJRWeOe8BwTAvbk376_pjzcLYRSQ@mail.gmail.com> (raw) In-Reply-To: <20200803120134.GD6132@gaia> On Mon, Aug 3, 2020 at 5:01 AM Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Mon, Aug 03, 2020 at 12:32:59PM +0300, Kirill A. Shutemov wrote: > > On Fri, Jul 31, 2020 at 01:32:41PM -0700, Peter Collingbourne wrote: > > > Introduce a new mmap flag, MAP_REFPAGE, that creates a mapping similar > > > to an anonymous mapping, but instead of clean pages being backed by the > > > zero page, they are instead backed by a so-called reference page, whose > > > address is specified using the offset argument to mmap. Loads from > > > the mapping will load directly from the reference page, and initial > > > stores to the mapping will copy-on-write from the reference page. > > > > > > Reference pages are useful in circumstances where anonymous mappings > > > combined with manual stores to memory would impose undesirable costs, > > > either in terms of performance or RSS. Use cases are focused on heap > > > allocators and include: > > > > > > - Pattern initialization for the heap. This is where malloc(3) gives > > > you memory whose contents are filled with a non-zero pattern > > > byte, in order to help detect and mitigate bugs involving use > > > of uninitialized memory. Typically this is implemented by having > > > the allocator memset the allocation with the pattern byte before > > > returning it to the user, but for large allocations this can result > > > in a significant increase in RSS, especially for allocations that > > > are used sparsely. Even for dense allocations there is a needless > > > impact to startup performance when it may be better to amortize it > > > throughout the program. By creating allocations using a reference > > > page filled with the pattern byte, we can avoid these costs. > > > > > > - Pre-tagged heap memory. Memory tagging [1] is an upcoming ARMv8.5 > > > feature which allows for memory to be tagged in order to detect > > > certain kinds of memory errors with low overhead. In order to set > > > up an allocation to allow memory errors to be detected, the entire > > > allocation needs to have the same tag. The issue here is similar to > > > pattern initialization in the sense that large tagged allocations > > > will be expensive if the tagging is done up front. The idea is that > > > the allocator would create reference pages with each of the possible > > > memory tags, and use those reference pages for the large allocations. > > > > Looks like it's wrong layer to implement the functionality. Just have a > > special fd that would return the same page for all vm_ops->fault and map > > the fd with normal mmap(MAP_PRIVATE, fd). It will get you what you want > > without touching core-mm. Thanks, I like this idea. I will try to implement it. > I think this would work even for the arm64 MTE (though I haven't tried): > use memfd_create() to get such file descriptor, mmap() it as MAP_SHARED > to populate the initial pattern, mmap() it as MAP_PRIVATE for any > subsequent mapping that needs to be copied-on-write. That would require a separate mmap() (i.e. separate VMA) for each page, no? That sounds like it could be expensive both in terms of VMAs and the number of mmap syscalls required (i.e. N/PAGE_SIZE). You could decrease these costs by increasing the size of the memfd files to more than a page, but that would also increase the amount of memory required for the reference pages. Peter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Collingbourne <pcc@google.com> To: Catalin Marinas <catalin.marinas@arm.com> Cc: "Kirill A. Shutemov" <kirill@shutemov.name>, Andrew Morton <akpm@linux-foundation.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Evgenii Stepanov <eugenis@google.com>, linux-mm@kvack.org Subject: Re: [PATCH] mm: introduce reference pages Date: Mon, 3 Aug 2020 17:50:32 -0700 [thread overview] Message-ID: <CAMn1gO54gTG5f1dVfZHAaXWJRWeOe8BwTAvbk376_pjzcLYRSQ@mail.gmail.com> (raw) In-Reply-To: <20200803120134.GD6132@gaia> On Mon, Aug 3, 2020 at 5:01 AM Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Mon, Aug 03, 2020 at 12:32:59PM +0300, Kirill A. Shutemov wrote: > > On Fri, Jul 31, 2020 at 01:32:41PM -0700, Peter Collingbourne wrote: > > > Introduce a new mmap flag, MAP_REFPAGE, that creates a mapping similar > > > to an anonymous mapping, but instead of clean pages being backed by the > > > zero page, they are instead backed by a so-called reference page, whose > > > address is specified using the offset argument to mmap. Loads from > > > the mapping will load directly from the reference page, and initial > > > stores to the mapping will copy-on-write from the reference page. > > > > > > Reference pages are useful in circumstances where anonymous mappings > > > combined with manual stores to memory would impose undesirable costs, > > > either in terms of performance or RSS. Use cases are focused on heap > > > allocators and include: > > > > > > - Pattern initialization for the heap. This is where malloc(3) gives > > > you memory whose contents are filled with a non-zero pattern > > > byte, in order to help detect and mitigate bugs involving use > > > of uninitialized memory. Typically this is implemented by having > > > the allocator memset the allocation with the pattern byte before > > > returning it to the user, but for large allocations this can result > > > in a significant increase in RSS, especially for allocations that > > > are used sparsely. Even for dense allocations there is a needless > > > impact to startup performance when it may be better to amortize it > > > throughout the program. By creating allocations using a reference > > > page filled with the pattern byte, we can avoid these costs. > > > > > > - Pre-tagged heap memory. Memory tagging [1] is an upcoming ARMv8.5 > > > feature which allows for memory to be tagged in order to detect > > > certain kinds of memory errors with low overhead. In order to set > > > up an allocation to allow memory errors to be detected, the entire > > > allocation needs to have the same tag. The issue here is similar to > > > pattern initialization in the sense that large tagged allocations > > > will be expensive if the tagging is done up front. The idea is that > > > the allocator would create reference pages with each of the possible > > > memory tags, and use those reference pages for the large allocations. > > > > Looks like it's wrong layer to implement the functionality. Just have a > > special fd that would return the same page for all vm_ops->fault and map > > the fd with normal mmap(MAP_PRIVATE, fd). It will get you what you want > > without touching core-mm. Thanks, I like this idea. I will try to implement it. > I think this would work even for the arm64 MTE (though I haven't tried): > use memfd_create() to get such file descriptor, mmap() it as MAP_SHARED > to populate the initial pattern, mmap() it as MAP_PRIVATE for any > subsequent mapping that needs to be copied-on-write. That would require a separate mmap() (i.e. separate VMA) for each page, no? That sounds like it could be expensive both in terms of VMAs and the number of mmap syscalls required (i.e. N/PAGE_SIZE). You could decrease these costs by increasing the size of the memfd files to more than a page, but that would also increase the amount of memory required for the reference pages. Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-08-04 0:50 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-31 20:32 [PATCH] mm: introduce reference pages Peter Collingbourne 2020-07-31 20:32 ` Peter Collingbourne 2020-08-03 3:28 ` John Hubbard 2020-08-03 3:28 ` John Hubbard 2020-08-03 3:51 ` Matthew Wilcox 2020-08-03 3:51 ` Matthew Wilcox 2020-08-13 22:03 ` Peter Collingbourne 2020-08-13 22:03 ` Peter Collingbourne 2020-08-13 22:03 ` Peter Collingbourne 2020-08-13 22:03 ` Peter Collingbourne 2020-08-03 9:32 ` Kirill A. Shutemov 2020-08-03 9:32 ` Kirill A. Shutemov 2020-08-03 12:01 ` Catalin Marinas 2020-08-03 12:01 ` Catalin Marinas 2020-08-04 0:50 ` Peter Collingbourne [this message] 2020-08-04 0:50 ` Peter Collingbourne 2020-08-04 15:27 ` Catalin Marinas 2020-08-04 15:27 ` Catalin Marinas 2020-08-04 15:48 ` Kirill A. Shutemov 2020-08-04 15:48 ` 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=CAMn1gO54gTG5f1dVfZHAaXWJRWeOe8BwTAvbk376_pjzcLYRSQ@mail.gmail.com \ --to=pcc@google.com \ --cc=akpm@linux-foundation.org \ --cc=catalin.marinas@arm.com \ --cc=eugenis@google.com \ --cc=kirill@shutemov.name \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mm@kvack.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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.