From: Nicholas Piggin <npiggin@gmail.com>
To: linux-mm@kvack.org
Cc: Nicholas Piggin <npiggin@gmail.com>, linux-arch@vger.kernel.org
Subject: [RFC PATCH 1/4] mm: munmap optimise single threaded page freeing
Date: Thu, 26 Jul 2018 01:52:43 +1000 [thread overview]
Message-ID: <20180725155246.1085-2-npiggin@gmail.com> (raw)
In-Reply-To: <20180725155246.1085-1-npiggin@gmail.com>
In case a single threaded process is zapping its own mappings, there
should be no concurrent memory accesses through the TLBs, and so it
is safe to free pages immediately rather than batch them up.
---
mm/memory.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index 135d18b31e44..773d588b371d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -296,6 +296,15 @@ bool __tlb_remove_page_size(struct mmu_gather *tlb, struct page *page, int page_
VM_BUG_ON(!tlb->end);
VM_WARN_ON(tlb->page_size != page_size);
+ /*
+ * When this is our mm and there are no other users, there can not be
+ * a concurrent memory access.
+ */
+ if (current->mm == tlb->mm && atomic_read(&tlb->mm->mm_users) < 2) {
+ free_page_and_swap_cache(page);
+ return false;
+ }
+
batch = tlb->active;
/*
* Add the page and check if we are full. If so
--
2.17.0
next prev parent reply other threads:[~2018-07-25 15:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-25 15:52 [RFC PATCH 0/4] possibilities for improving invalidations Nicholas Piggin
2018-07-25 15:52 ` Nicholas Piggin [this message]
2018-07-25 15:52 ` [RFC PATCH 2/4] mm: zap_pte_range only flush under ptl if a dirty shared page was unmapped Nicholas Piggin
2018-07-25 15:52 ` [RFC PATCH 3/4] mm: zap_pte_range optimise fullmm handling for dirty shared pages Nicholas Piggin
2018-07-25 15:52 ` [RFC PATCH 4/4] mm: optimise flushing and pte manipulation for single threaded access 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=20180725155246.1085-2-npiggin@gmail.com \
--to=npiggin@gmail.com \
--cc=linux-arch@vger.kernel.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: 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).