From: Nicholas Piggin <npiggin@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-arch <linux-arch@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Nicholas Piggin <npiggin@gmail.com>,
linux-mm <linux-mm@kvack.org>,
Ley Foon Tan <ley.foon.tan@intel.com>,
ppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: [PATCH v2 4/5] mm/cow: optimise pte dirty bit handling in fork
Date: Tue, 16 Oct 2018 23:13:42 +1000 [thread overview]
Message-ID: <20181016131343.20556-5-npiggin@gmail.com> (raw)
In-Reply-To: <20181016131343.20556-1-npiggin@gmail.com>
fork clears dirty/accessed bits from new ptes in the child. This logic
has existed since mapped page reclaim was done by scanning ptes when
it may have been quite important. Today with physical based pte
scanning, there is less reason to clear these bits, so this patch
avoids clearing the dirty bit in the child.
Dirty bits are all tested and cleared together, and any dirty bit is
the same as many dirty bits, so from a correctness and writeback
bandwidth point-of-view it does not matter if the child gets a dirty
bit.
Dirty ptes are more costly to unmap because they require flushing
under the page table lock, but it is pretty rare to have a shared
dirty mapping that is copied on fork, so just simplify the code and
avoid this dirty clearing logic.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
mm/memory.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 0387ee1e3582..9e314339a0bd 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1028,11 +1028,12 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct *src_mm,
}
/*
- * If it's a shared mapping, mark it clean in
- * the child
+ * Child inherits dirty and young bits from parent. There is no
+ * point clearing them because any cleaning or aging has to walk
+ * all ptes anyway, and it will notice the bits set in the parent.
+ * Leaving them set avoids stalls and even page faults on CPUs that
+ * handle these bits in software.
*/
- if (vm_flags & VM_SHARED)
- pte = pte_mkclean(pte);
page = vm_normal_page(vma, addr, pte);
if (page) {
--
2.18.0
next prev parent reply other threads:[~2018-10-16 13:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-16 13:13 [PATCH v2 0/5] mm: dirty/accessed pte optimisations Nicholas Piggin
2018-10-16 13:13 ` [PATCH v2 1/5] nios2: update_mmu_cache clear the old entry from the TLB Nicholas Piggin
2018-10-16 13:13 ` [PATCH v2 2/5] mm/cow: don't bother write protecting already write-protected huge pages Nicholas Piggin
2018-10-16 13:13 ` [PATCH v2 3/5] mm/cow: optimise pte accessed bit handling in fork Nicholas Piggin
2018-10-16 13:13 ` Nicholas Piggin [this message]
2018-10-16 13:13 ` [PATCH v2 5/5] mm: optimise pte dirty/accessed bit setting by demand based pte insertion Nicholas Piggin
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=20181016131343.20556-5-npiggin@gmail.com \
--to=npiggin@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=ley.foon.tan@intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=torvalds@linux-foundation.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: link
Be 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).