From: Andy Lutomirski <luto@kernel.org>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linux-arch <linux-arch@vger.kernel.org>,
Nadav Amit <nadav.amit@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
Rik van Riel <riel@surriel.com>, Will Deacon <will@kernel.org>,
X86 ML <x86@kernel.org>, Dave Hansen <dave.hansen@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andy Lutomirski <luto@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jann Horn <jannh@google.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: [RFC v2 0/2] lazy mm refcounting
Date: Thu, 3 Dec 2020 21:26:15 -0800 [thread overview]
Message-ID: <cover.1607059162.git.luto@kernel.org> (raw)
This is part of a larger series here, but the beginning bit is irrelevant
to the current discussion:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/mm&id=203d39d11562575fd8bd6a094d97a3a332d8b265
This is IMO a lot better than v1. It's now almost entirely in generic
code. (It looks like it's 100% generic, but that's a lie -- the
generic code currently that all possible lazy mm refs are in
mm_cpumask(), and that's not true on all arches. So, if we take my
approach, we'll need to have a little arch hook to control this.)
Here's how I think it fits with various arches:
x86: On bare metal (i.e. paravirt flush unavailable), the loop won't do
much. The existing TLB shootdown when user tables are freed will
empty mm_cpumask of everything but the calling CPU. So x86 ends up
pretty close to as good as we can get short of reworking mm_cpumask() itself.
arm64: It needs the fixup above for correctness, but I think performance
should be pretty good. Compared to current kernels, we lose an mmgrab()
and mmdrop() on each lazy transition, and we add a reasonably fast loop
over all cpus on process exit. Someone (probably me) needs to make
sure we don't need some extra barriers.
power: Similar to x86.
s390x: Should be essentially the same as arm64.
Other arches: I don't know. Further research is required.
What do you all think?
Andy Lutomirski (2):
[NEEDS HELP] x86/mm: Handle unlazying membarrier core sync in the arch
code
[MOCKUP] sched/mm: Lightweight lazy mm refcounting
arch/x86/mm/tlb.c | 17 +++++-
kernel/fork.c | 4 ++
kernel/sched/core.c | 134 +++++++++++++++++++++++++++++++++++++------
kernel/sched/sched.h | 11 +++-
4 files changed, 145 insertions(+), 21 deletions(-)
--
2.28.0
next reply other threads:[~2020-12-04 5:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 5:26 Andy Lutomirski [this message]
2020-12-04 5:26 ` [RFC v2 1/2] [NEEDS HELP] x86/mm: Handle unlazying membarrier core sync in the arch code Andy Lutomirski
2020-12-04 7:06 ` Nicholas Piggin
2020-12-04 8:17 ` Nadav Amit
2020-12-04 20:39 ` Mathieu Desnoyers
2020-12-04 20:24 ` Mathieu Desnoyers
2020-12-04 5:26 ` [RFC v2 2/2] [MOCKUP] sched/mm: Lightweight lazy mm refcounting Andy Lutomirski
2020-12-04 7:54 ` Nicholas Piggin
2020-12-04 14:37 ` Andy Lutomirski
2020-12-05 4:49 ` 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=cover.1607059162.git.luto@kernel.org \
--to=luto@kernel.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@intel.com \
--cc=jannh@google.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=mathieu.desnoyers@efficios.com \
--cc=nadav.amit@gmail.com \
--cc=npiggin@gmail.com \
--cc=riel@surriel.com \
--cc=will@kernel.org \
--cc=x86@kernel.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).