2019-05-27 00:55:01 -06:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2016-04-29 07:26:05 -06:00
|
|
|
/*
|
|
|
|
|
* TLB flush routines for radix kernels.
|
|
|
|
|
*
|
|
|
|
|
* Copyright 2015-2016, Aneesh Kumar K.V, IBM Corporation.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/mm.h>
|
|
|
|
|
#include <linux/hugetlb.h>
|
|
|
|
|
#include <linux/memblock.h>
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
#include <linux/mmu_context.h>
|
|
|
|
|
#include <linux/sched/mm.h>
|
2016-04-29 07:26:05 -06:00
|
|
|
|
powerpc/mm/radix: Workaround prefetch issue with KVM
There's a somewhat architectural issue with Radix MMU and KVM.
When coming out of a guest with AIL (Alternate Interrupt Location, ie,
MMU enabled), we start executing hypervisor code with the PID register
still containing whatever the guest has been using.
The problem is that the CPU can (and will) then start prefetching or
speculatively load from whatever host context has that same PID (if
any), thus bringing translations for that context into the TLB, which
Linux doesn't know about.
This can cause stale translations and subsequent crashes.
Fixing this in a way that is neither racy nor a huge performance
impact is difficult. We could just make the host invalidations always
use broadcast forms but that would hurt single threaded programs for
example.
We chose to fix it instead by partitioning the PID space between guest
and host. This is possible because today Linux only use 19 out of the
20 bits of PID space, so existing guests will work if we make the host
use the top half of the 20 bits space.
We additionally add support for a property to indicate to Linux the
size of the PID register which will be useful if we eventually have
processors with a larger PID space available.
There is still an issue with malicious guests purposefully setting the
PID register to a value in the hosts PID range. Hopefully future HW
can prevent that, but in the meantime, we handle it with a pair of
kludges:
- On the way out of a guest, before we clear the current VCPU in the
PACA, we check the PID and if it's outside of the permitted range
we flush the TLB for that PID.
- When context switching, if the mm is "new" on that CPU (the
corresponding bit was set for the first time in the mm cpumask), we
check if any sibling thread is in KVM (has a non-NULL VCPU pointer
in the PACA). If that is the case, we also flush the PID for that
CPU (core).
This second part is needed to handle the case where a process is
migrated (or starts a new pthread) on a sibling thread of the CPU
coming out of KVM, as there's a window where stale translations can
exist before we detect it and flush them out.
A future optimization could be added by keeping track of whether the
PID has ever been used and avoid doing that for completely fresh PIDs.
We could similarily mark PIDs that have been the subject of a global
invalidation as "fresh". But for now this will do.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[mpe: Rework the asm to build with CONFIG_PPC_RADIX_MMU=n, drop
unneeded include of kvm_book3s_asm.h]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-23 22:26:06 -06:00
|
|
|
#include <asm/ppc-opcode.h>
|
2016-04-29 07:26:05 -06:00
|
|
|
#include <asm/tlb.h>
|
|
|
|
|
#include <asm/tlbflush.h>
|
2017-04-10 23:23:25 -06:00
|
|
|
#include <asm/trace.h>
|
powerpc/mm/radix: Workaround prefetch issue with KVM
There's a somewhat architectural issue with Radix MMU and KVM.
When coming out of a guest with AIL (Alternate Interrupt Location, ie,
MMU enabled), we start executing hypervisor code with the PID register
still containing whatever the guest has been using.
The problem is that the CPU can (and will) then start prefetching or
speculatively load from whatever host context has that same PID (if
any), thus bringing translations for that context into the TLB, which
Linux doesn't know about.
This can cause stale translations and subsequent crashes.
Fixing this in a way that is neither racy nor a huge performance
impact is difficult. We could just make the host invalidations always
use broadcast forms but that would hurt single threaded programs for
example.
We chose to fix it instead by partitioning the PID space between guest
and host. This is possible because today Linux only use 19 out of the
20 bits of PID space, so existing guests will work if we make the host
use the top half of the 20 bits space.
We additionally add support for a property to indicate to Linux the
size of the PID register which will be useful if we eventually have
processors with a larger PID space available.
There is still an issue with malicious guests purposefully setting the
PID register to a value in the hosts PID range. Hopefully future HW
can prevent that, but in the meantime, we handle it with a pair of
kludges:
- On the way out of a guest, before we clear the current VCPU in the
PACA, we check the PID and if it's outside of the permitted range
we flush the TLB for that PID.
- When context switching, if the mm is "new" on that CPU (the
corresponding bit was set for the first time in the mm cpumask), we
check if any sibling thread is in KVM (has a non-NULL VCPU pointer
in the PACA). If that is the case, we also flush the PID for that
CPU (core).
This second part is needed to handle the case where a process is
migrated (or starts a new pthread) on a sibling thread of the CPU
coming out of KVM, as there's a window where stale translations can
exist before we detect it and flush them out.
A future optimization could be added by keeping track of whether the
PID has ever been used and avoid doing that for completely fresh PIDs.
We could similarily mark PIDs that have been the subject of a global
invalidation as "fresh". But for now this will do.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[mpe: Rework the asm to build with CONFIG_PPC_RADIX_MMU=n, drop
unneeded include of kvm_book3s_asm.h]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-23 22:26:06 -06:00
|
|
|
#include <asm/cputhreads.h>
|
2016-04-29 07:26:05 -06:00
|
|
|
|
2016-06-08 08:25:50 -06:00
|
|
|
#define RIC_FLUSH_TLB 0
|
|
|
|
|
#define RIC_FLUSH_PWC 1
|
|
|
|
|
#define RIC_FLUSH_ALL 2
|
|
|
|
|
|
powerpc/64s: Improve local TLB flush for boot and MCE on POWER9
There are several cases outside the normal address space management
where a CPU's entire local TLB is to be flushed:
1. Booting the kernel, in case something has left stale entries in
the TLB (e.g., kexec).
2. Machine check, to clean corrupted TLB entries.
One other place where the TLB is flushed, is waking from deep idle
states. The flush is a side-effect of calling ->cpu_restore with the
intention of re-setting various SPRs. The flush itself is unnecessary
because in the first case, the TLB should not acquire new corrupted
TLB entries as part of sleep/wake (though they may be lost).
This type of TLB flush is coded inflexibly, several times for each CPU
type, and they have a number of problems with ISA v3.0B:
- The current radix mode of the MMU is not taken into account, it is
always done as a hash flushn For IS=2 (LPID-matching flush from host)
and IS=3 with HV=0 (guest kernel flush), tlbie(l) is undefined if
the R field does not match the current radix mode.
- ISA v3.0B hash must flush the partition and process table caches as
well.
- ISA v3.0B radix must flush partition and process scoped translations,
partition and process table caches, and also the page walk cache.
So consolidate the flushing code and implement it in C and inline asm
under the mm/ directory with the rest of the flush code. Add ISA v3.0B
cases for radix and hash, and use the radix flush in radix environment.
Provide a way for IS=2 (LPID flush) to specify the radix mode of the
partition. Have KVM pass in the radix mode of the guest.
Take out the flushes from early cputable/dt_cpu_ftrs detection hooks,
and move it later in the boot process after, the MMU registers are set
up and before relocation is first turned on.
The TLB flush is no longer called when restoring from deep idle states.
This was not be done as a separate step because booting secondaries
uses the same cpu_restore as idle restore, which needs the TLB flush.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-12-23 08:15:50 -07:00
|
|
|
/*
|
|
|
|
|
* tlbiel instruction for radix, set invalidation
|
|
|
|
|
* i.e., r=1 and is=01 or is=10 or is=11
|
|
|
|
|
*/
|
|
|
|
|
static inline void tlbiel_radix_set_isa300(unsigned int set, unsigned int is,
|
|
|
|
|
unsigned int pid,
|
|
|
|
|
unsigned int ric, unsigned int prs)
|
|
|
|
|
{
|
|
|
|
|
unsigned long rb;
|
|
|
|
|
unsigned long rs;
|
|
|
|
|
|
|
|
|
|
rb = (set << PPC_BITLSHIFT(51)) | (is << PPC_BITLSHIFT(53));
|
|
|
|
|
rs = ((unsigned long)pid << PPC_BITLSHIFT(31));
|
|
|
|
|
|
powerpc/mm/radix: Fix checkstops caused by invalid tlbiel
In tlbiel_radix_set_isa300() we use the PPC_TLBIEL() macro to
construct tlbiel instructions. The instruction takes 5 fields, two of
which are registers, and the others are constants. But because it's
constructed with inline asm the compiler doesn't know that.
We got the constraint wrong on the 'r' field, using "r" tells the
compiler to put the value in a register. The value we then get in the
macro is the *register number*, not the value of the field.
That means when we mask the register number with 0x1 we get 0 or 1
depending on which register the compiler happens to put the constant
in, eg:
li r10,1
tlbiel r8,r9,2,0,0
li r7,1
tlbiel r10,r6,0,0,1
If we're unlucky we might generate an invalid instruction form, for
example RIC=0, PRS=1 and R=0, tlbiel r8,r7,0,1,0, this has been
observed to cause machine checks:
Oops: Machine check, sig: 7 [#1]
CPU: 24 PID: 0 Comm: swapper
NIP: 00000000000385f4 LR: 000000000100ed00 CTR: 000000000000007f
REGS: c00000000110bb40 TRAP: 0200
MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 48002222 XER: 20040000
CFAR: 00000000000385d0 DAR: 0000000000001c00 DSISR: 00000200 SOFTE: 1
If the machine check happens early in boot while we have MSR_ME=0 it
will escalate into a checkstop and kill the box entirely.
To fix it we could change the inline asm constraint to "i" which
tells the compiler the value is a constant. But a better fix is to just
pass a literal 1 into the macro, which bypasses any problems with inline
asm constraints.
Fixes: d4748276ae14 ("powerpc/64s: Improve local TLB flush for boot and MCE on POWER9")
Cc: stable@vger.kernel.org # v4.16+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
2018-04-11 19:35:55 -06:00
|
|
|
asm volatile(PPC_TLBIEL(%0, %1, %2, %3, 1)
|
|
|
|
|
: : "r"(rb), "r"(rs), "i"(ric), "i"(prs)
|
powerpc/64s: Improve local TLB flush for boot and MCE on POWER9
There are several cases outside the normal address space management
where a CPU's entire local TLB is to be flushed:
1. Booting the kernel, in case something has left stale entries in
the TLB (e.g., kexec).
2. Machine check, to clean corrupted TLB entries.
One other place where the TLB is flushed, is waking from deep idle
states. The flush is a side-effect of calling ->cpu_restore with the
intention of re-setting various SPRs. The flush itself is unnecessary
because in the first case, the TLB should not acquire new corrupted
TLB entries as part of sleep/wake (though they may be lost).
This type of TLB flush is coded inflexibly, several times for each CPU
type, and they have a number of problems with ISA v3.0B:
- The current radix mode of the MMU is not taken into account, it is
always done as a hash flushn For IS=2 (LPID-matching flush from host)
and IS=3 with HV=0 (guest kernel flush), tlbie(l) is undefined if
the R field does not match the current radix mode.
- ISA v3.0B hash must flush the partition and process table caches as
well.
- ISA v3.0B radix must flush partition and process scoped translations,
partition and process table caches, and also the page walk cache.
So consolidate the flushing code and implement it in C and inline asm
under the mm/ directory with the rest of the flush code. Add ISA v3.0B
cases for radix and hash, and use the radix flush in radix environment.
Provide a way for IS=2 (LPID flush) to specify the radix mode of the
partition. Have KVM pass in the radix mode of the guest.
Take out the flushes from early cputable/dt_cpu_ftrs detection hooks,
and move it later in the boot process after, the MMU registers are set
up and before relocation is first turned on.
The TLB flush is no longer called when restoring from deep idle states.
This was not be done as a separate step because booting secondaries
uses the same cpu_restore as idle restore, which needs the TLB flush.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-12-23 08:15:50 -07:00
|
|
|
: "memory");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void tlbiel_all_isa300(unsigned int num_sets, unsigned int is)
|
|
|
|
|
{
|
|
|
|
|
unsigned int set;
|
|
|
|
|
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Flush the first set of the TLB, and the entire Page Walk Cache
|
|
|
|
|
* and partition table entries. Then flush the remaining sets of the
|
|
|
|
|
* TLB.
|
|
|
|
|
*/
|
|
|
|
|
tlbiel_radix_set_isa300(0, is, 0, RIC_FLUSH_ALL, 0);
|
|
|
|
|
for (set = 1; set < num_sets; set++)
|
|
|
|
|
tlbiel_radix_set_isa300(set, is, 0, RIC_FLUSH_TLB, 0);
|
|
|
|
|
|
|
|
|
|
/* Do the same for process scoped entries. */
|
|
|
|
|
tlbiel_radix_set_isa300(0, is, 0, RIC_FLUSH_ALL, 1);
|
|
|
|
|
for (set = 1; set < num_sets; set++)
|
|
|
|
|
tlbiel_radix_set_isa300(set, is, 0, RIC_FLUSH_TLB, 1);
|
|
|
|
|
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void radix__tlbiel_all(unsigned int action)
|
|
|
|
|
{
|
|
|
|
|
unsigned int is;
|
|
|
|
|
|
|
|
|
|
switch (action) {
|
|
|
|
|
case TLB_INVAL_SCOPE_GLOBAL:
|
|
|
|
|
is = 3;
|
|
|
|
|
break;
|
|
|
|
|
case TLB_INVAL_SCOPE_LPID:
|
|
|
|
|
is = 2;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
BUG();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (early_cpu_has_feature(CPU_FTR_ARCH_300))
|
|
|
|
|
tlbiel_all_isa300(POWER9_TLB_SETS_RADIX, is);
|
|
|
|
|
else
|
|
|
|
|
WARN(1, "%s called on pre-POWER9 CPU\n", __func__);
|
|
|
|
|
|
|
|
|
|
asm volatile(PPC_INVALIDATE_ERAT "; isync" : : :"memory");
|
|
|
|
|
}
|
|
|
|
|
|
powerpc/mm/radix: mark as __tlbie_pid() and friends as__always_inline
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for powerpc, the following errors are reported:
arch/powerpc/mm/tlb-radix.c: In function '__tlbie_lpid':
arch/powerpc/mm/tlb-radix.c:148:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
^~~
arch/powerpc/mm/tlb-radix.c:148:2: error: impossible constraint in 'asm'
arch/powerpc/mm/tlb-radix.c: In function '__tlbie_pid':
arch/powerpc/mm/tlb-radix.c:118:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
^~~
arch/powerpc/mm/tlb-radix.c: In function '__tlbiel_pid':
arch/powerpc/mm/tlb-radix.c:104:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
^~~
Link: http://lkml.kernel.org/r/20190423034959.13525-11-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Malaterre <malat@debian.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 16:42:21 -06:00
|
|
|
static __always_inline void __tlbiel_pid(unsigned long pid, int set,
|
2016-06-08 08:25:50 -06:00
|
|
|
unsigned long ric)
|
2016-04-29 07:26:05 -06:00
|
|
|
{
|
2016-06-08 08:25:50 -06:00
|
|
|
unsigned long rb,rs,prs,r;
|
2016-04-29 07:26:05 -06:00
|
|
|
|
|
|
|
|
rb = PPC_BIT(53); /* IS = 1 */
|
|
|
|
|
rb |= set << PPC_BITLSHIFT(51);
|
|
|
|
|
rs = ((unsigned long)pid) << PPC_BITLSHIFT(31);
|
|
|
|
|
prs = 1; /* process scoped */
|
2018-01-31 22:07:25 -07:00
|
|
|
r = 1; /* radix format */
|
2016-04-29 07:26:05 -06:00
|
|
|
|
2016-07-13 03:35:20 -06:00
|
|
|
asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
|
2016-04-29 07:26:05 -06:00
|
|
|
: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) : "memory");
|
2017-04-10 23:23:25 -06:00
|
|
|
trace_tlbie(0, 1, rb, rs, ric, prs, r);
|
2016-04-29 07:26:05 -06:00
|
|
|
}
|
|
|
|
|
|
powerpc/mm/radix: mark as __tlbie_pid() and friends as__always_inline
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for powerpc, the following errors are reported:
arch/powerpc/mm/tlb-radix.c: In function '__tlbie_lpid':
arch/powerpc/mm/tlb-radix.c:148:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
^~~
arch/powerpc/mm/tlb-radix.c:148:2: error: impossible constraint in 'asm'
arch/powerpc/mm/tlb-radix.c: In function '__tlbie_pid':
arch/powerpc/mm/tlb-radix.c:118:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
^~~
arch/powerpc/mm/tlb-radix.c: In function '__tlbiel_pid':
arch/powerpc/mm/tlb-radix.c:104:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
^~~
Link: http://lkml.kernel.org/r/20190423034959.13525-11-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Malaterre <malat@debian.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 16:42:21 -06:00
|
|
|
static __always_inline void __tlbie_pid(unsigned long pid, unsigned long ric)
|
2017-11-07 00:53:09 -07:00
|
|
|
{
|
|
|
|
|
unsigned long rb,rs,prs,r;
|
|
|
|
|
|
|
|
|
|
rb = PPC_BIT(53); /* IS = 1 */
|
|
|
|
|
rs = pid << PPC_BITLSHIFT(31);
|
|
|
|
|
prs = 1; /* process scoped */
|
2018-01-31 22:07:25 -07:00
|
|
|
r = 1; /* radix format */
|
2017-11-07 00:53:09 -07:00
|
|
|
|
|
|
|
|
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) : "memory");
|
|
|
|
|
trace_tlbie(0, 0, rb, rs, ric, prs, r);
|
|
|
|
|
}
|
|
|
|
|
|
powerpc/mm/radix: mark as __tlbie_pid() and friends as__always_inline
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for powerpc, the following errors are reported:
arch/powerpc/mm/tlb-radix.c: In function '__tlbie_lpid':
arch/powerpc/mm/tlb-radix.c:148:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
^~~
arch/powerpc/mm/tlb-radix.c:148:2: error: impossible constraint in 'asm'
arch/powerpc/mm/tlb-radix.c: In function '__tlbie_pid':
arch/powerpc/mm/tlb-radix.c:118:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
^~~
arch/powerpc/mm/tlb-radix.c: In function '__tlbiel_pid':
arch/powerpc/mm/tlb-radix.c:104:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
^~~
Link: http://lkml.kernel.org/r/20190423034959.13525-11-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Malaterre <malat@debian.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 16:42:21 -06:00
|
|
|
static __always_inline void __tlbiel_lpid(unsigned long lpid, int set,
|
2018-05-08 20:20:18 -06:00
|
|
|
unsigned long ric)
|
|
|
|
|
{
|
|
|
|
|
unsigned long rb,rs,prs,r;
|
|
|
|
|
|
|
|
|
|
rb = PPC_BIT(52); /* IS = 2 */
|
|
|
|
|
rb |= set << PPC_BITLSHIFT(51);
|
|
|
|
|
rs = 0; /* LPID comes from LPIDR */
|
|
|
|
|
prs = 0; /* partition scoped */
|
|
|
|
|
r = 1; /* radix format */
|
|
|
|
|
|
|
|
|
|
asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) : "memory");
|
|
|
|
|
trace_tlbie(lpid, 1, rb, rs, ric, prs, r);
|
|
|
|
|
}
|
|
|
|
|
|
powerpc/mm/radix: mark as __tlbie_pid() and friends as__always_inline
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
If it is enabled for powerpc, the following errors are reported:
arch/powerpc/mm/tlb-radix.c: In function '__tlbie_lpid':
arch/powerpc/mm/tlb-radix.c:148:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
^~~
arch/powerpc/mm/tlb-radix.c:148:2: error: impossible constraint in 'asm'
arch/powerpc/mm/tlb-radix.c: In function '__tlbie_pid':
arch/powerpc/mm/tlb-radix.c:118:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
^~~
arch/powerpc/mm/tlb-radix.c: In function '__tlbiel_pid':
arch/powerpc/mm/tlb-radix.c:104:2: warning: asm operand 3 probably doesn't match constraints
asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
^~~
Link: http://lkml.kernel.org/r/20190423034959.13525-11-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Boris Brezillon <bbrezillon@kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Malaterre <malat@debian.org>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-14 16:42:21 -06:00
|
|
|
static __always_inline void __tlbie_lpid(unsigned long lpid, unsigned long ric)
|
2018-05-08 20:20:18 -06:00
|
|
|
{
|
|
|
|
|
unsigned long rb,rs,prs,r;
|
|
|
|
|
|
|
|
|
|
rb = PPC_BIT(52); /* IS = 2 */
|
|
|
|
|
rs = lpid;
|
|
|
|
|
prs = 0; /* partition scoped */
|
|
|
|
|
r = 1; /* radix format */
|
|
|
|
|
|
|
|
|
|
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) : "memory");
|
|
|
|
|
trace_tlbie(lpid, 0, rb, rs, ric, prs, r);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void __tlbiel_lpid_guest(unsigned long lpid, int set,
|
|
|
|
|
unsigned long ric)
|
|
|
|
|
{
|
|
|
|
|
unsigned long rb,rs,prs,r;
|
|
|
|
|
|
|
|
|
|
rb = PPC_BIT(52); /* IS = 2 */
|
|
|
|
|
rb |= set << PPC_BITLSHIFT(51);
|
|
|
|
|
rs = 0; /* LPID comes from LPIDR */
|
|
|
|
|
prs = 1; /* process scoped */
|
|
|
|
|
r = 1; /* radix format */
|
|
|
|
|
|
|
|
|
|
asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) : "memory");
|
|
|
|
|
trace_tlbie(lpid, 1, rb, rs, ric, prs, r);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2018-03-22 22:56:26 -06:00
|
|
|
static inline void __tlbiel_va(unsigned long va, unsigned long pid,
|
|
|
|
|
unsigned long ap, unsigned long ric)
|
|
|
|
|
{
|
|
|
|
|
unsigned long rb,rs,prs,r;
|
|
|
|
|
|
|
|
|
|
rb = va & ~(PPC_BITMASK(52, 63));
|
|
|
|
|
rb |= ap << PPC_BITLSHIFT(58);
|
|
|
|
|
rs = pid << PPC_BITLSHIFT(31);
|
|
|
|
|
prs = 1; /* process scoped */
|
2018-03-28 05:59:50 -06:00
|
|
|
r = 1; /* radix format */
|
2018-03-22 22:56:26 -06:00
|
|
|
|
|
|
|
|
asm volatile(PPC_TLBIEL(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) : "memory");
|
|
|
|
|
trace_tlbie(0, 1, rb, rs, ric, prs, r);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void __tlbie_va(unsigned long va, unsigned long pid,
|
|
|
|
|
unsigned long ap, unsigned long ric)
|
|
|
|
|
{
|
|
|
|
|
unsigned long rb,rs,prs,r;
|
|
|
|
|
|
|
|
|
|
rb = va & ~(PPC_BITMASK(52, 63));
|
|
|
|
|
rb |= ap << PPC_BITLSHIFT(58);
|
|
|
|
|
rs = pid << PPC_BITLSHIFT(31);
|
|
|
|
|
prs = 1; /* process scoped */
|
2018-03-28 05:59:50 -06:00
|
|
|
r = 1; /* radix format */
|
2018-03-22 22:56:26 -06:00
|
|
|
|
|
|
|
|
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) : "memory");
|
|
|
|
|
trace_tlbie(0, 0, rb, rs, ric, prs, r);
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-08 20:20:18 -06:00
|
|
|
static inline void __tlbie_lpid_va(unsigned long va, unsigned long lpid,
|
|
|
|
|
unsigned long ap, unsigned long ric)
|
|
|
|
|
{
|
|
|
|
|
unsigned long rb,rs,prs,r;
|
|
|
|
|
|
|
|
|
|
rb = va & ~(PPC_BITMASK(52, 63));
|
|
|
|
|
rb |= ap << PPC_BITLSHIFT(58);
|
|
|
|
|
rs = lpid;
|
|
|
|
|
prs = 0; /* partition scoped */
|
|
|
|
|
r = 1; /* radix format */
|
|
|
|
|
|
|
|
|
|
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(rs) : "memory");
|
|
|
|
|
trace_tlbie(lpid, 0, rb, rs, ric, prs, r);
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-22 22:56:27 -06:00
|
|
|
static inline void fixup_tlbie(void)
|
|
|
|
|
{
|
|
|
|
|
unsigned long pid = 0;
|
|
|
|
|
unsigned long va = ((1UL << 52) - 1);
|
|
|
|
|
|
|
|
|
|
if (cpu_has_feature(CPU_FTR_P9_TLBIE_BUG)) {
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
__tlbie_va(va, pid, mmu_get_ap(MMU_PAGE_64K), RIC_FLUSH_TLB);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-08 20:20:18 -06:00
|
|
|
static inline void fixup_tlbie_lpid(unsigned long lpid)
|
|
|
|
|
{
|
|
|
|
|
unsigned long va = ((1UL << 52) - 1);
|
|
|
|
|
|
|
|
|
|
if (cpu_has_feature(CPU_FTR_P9_TLBIE_BUG)) {
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
__tlbie_lpid_va(va, lpid, mmu_get_ap(MMU_PAGE_64K), RIC_FLUSH_TLB);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-04-29 07:26:05 -06:00
|
|
|
/*
|
|
|
|
|
* We use 128 set in radix mode and 256 set in hpt mode.
|
|
|
|
|
*/
|
2016-06-08 08:25:50 -06:00
|
|
|
static inline void _tlbiel_pid(unsigned long pid, unsigned long ric)
|
2016-04-29 07:26:05 -06:00
|
|
|
{
|
|
|
|
|
int set;
|
|
|
|
|
|
2017-04-01 08:41:48 -06:00
|
|
|
asm volatile("ptesync": : :"memory");
|
2017-04-26 05:38:17 -06:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Flush the first set of the TLB, and if we're doing a RIC_FLUSH_ALL,
|
|
|
|
|
* also flush the entire Page Walk Cache.
|
|
|
|
|
*/
|
|
|
|
|
__tlbiel_pid(pid, 0, ric);
|
|
|
|
|
|
2017-07-18 22:49:04 -06:00
|
|
|
/* For PWC, only one flush is needed */
|
|
|
|
|
if (ric == RIC_FLUSH_PWC) {
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
return;
|
|
|
|
|
}
|
2017-04-26 05:38:17 -06:00
|
|
|
|
2017-07-18 22:49:04 -06:00
|
|
|
/* For the remaining sets, just flush the TLB */
|
2017-04-26 05:38:17 -06:00
|
|
|
for (set = 1; set < POWER9_TLB_SETS_RADIX ; set++)
|
2017-07-18 22:49:04 -06:00
|
|
|
__tlbiel_pid(pid, set, RIC_FLUSH_TLB);
|
2017-04-26 05:38:17 -06:00
|
|
|
|
2017-04-01 08:41:48 -06:00
|
|
|
asm volatile("ptesync": : :"memory");
|
2017-02-05 19:05:16 -07:00
|
|
|
asm volatile(PPC_INVALIDATE_ERAT "; isync" : : :"memory");
|
2016-04-29 07:26:05 -06:00
|
|
|
}
|
|
|
|
|
|
2016-06-08 08:25:50 -06:00
|
|
|
static inline void _tlbie_pid(unsigned long pid, unsigned long ric)
|
2016-04-29 07:26:05 -06:00
|
|
|
{
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
|
2018-03-22 16:29:06 -06:00
|
|
|
/*
|
|
|
|
|
* Workaround the fact that the "ric" argument to __tlbie_pid
|
|
|
|
|
* must be a compile-time contraint to match the "i" constraint
|
|
|
|
|
* in the asm statement.
|
|
|
|
|
*/
|
|
|
|
|
switch (ric) {
|
|
|
|
|
case RIC_FLUSH_TLB:
|
|
|
|
|
__tlbie_pid(pid, RIC_FLUSH_TLB);
|
|
|
|
|
break;
|
|
|
|
|
case RIC_FLUSH_PWC:
|
|
|
|
|
__tlbie_pid(pid, RIC_FLUSH_PWC);
|
|
|
|
|
break;
|
|
|
|
|
case RIC_FLUSH_ALL:
|
|
|
|
|
default:
|
|
|
|
|
__tlbie_pid(pid, RIC_FLUSH_ALL);
|
|
|
|
|
}
|
2018-03-22 22:56:27 -06:00
|
|
|
fixup_tlbie();
|
2016-04-29 07:26:05 -06:00
|
|
|
asm volatile("eieio; tlbsync; ptesync": : :"memory");
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-08 20:20:18 -06:00
|
|
|
static inline void _tlbiel_lpid(unsigned long lpid, unsigned long ric)
|
|
|
|
|
{
|
|
|
|
|
int set;
|
|
|
|
|
|
|
|
|
|
VM_BUG_ON(mfspr(SPRN_LPID) != lpid);
|
|
|
|
|
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Flush the first set of the TLB, and if we're doing a RIC_FLUSH_ALL,
|
|
|
|
|
* also flush the entire Page Walk Cache.
|
|
|
|
|
*/
|
|
|
|
|
__tlbiel_lpid(lpid, 0, ric);
|
|
|
|
|
|
|
|
|
|
/* For PWC, only one flush is needed */
|
|
|
|
|
if (ric == RIC_FLUSH_PWC) {
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* For the remaining sets, just flush the TLB */
|
|
|
|
|
for (set = 1; set < POWER9_TLB_SETS_RADIX ; set++)
|
|
|
|
|
__tlbiel_lpid(lpid, set, RIC_FLUSH_TLB);
|
|
|
|
|
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
asm volatile(PPC_INVALIDATE_ERAT "; isync" : : :"memory");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void _tlbie_lpid(unsigned long lpid, unsigned long ric)
|
|
|
|
|
{
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Workaround the fact that the "ric" argument to __tlbie_pid
|
|
|
|
|
* must be a compile-time contraint to match the "i" constraint
|
|
|
|
|
* in the asm statement.
|
|
|
|
|
*/
|
|
|
|
|
switch (ric) {
|
|
|
|
|
case RIC_FLUSH_TLB:
|
|
|
|
|
__tlbie_lpid(lpid, RIC_FLUSH_TLB);
|
|
|
|
|
break;
|
|
|
|
|
case RIC_FLUSH_PWC:
|
|
|
|
|
__tlbie_lpid(lpid, RIC_FLUSH_PWC);
|
|
|
|
|
break;
|
|
|
|
|
case RIC_FLUSH_ALL:
|
|
|
|
|
default:
|
|
|
|
|
__tlbie_lpid(lpid, RIC_FLUSH_ALL);
|
|
|
|
|
}
|
|
|
|
|
fixup_tlbie_lpid(lpid);
|
|
|
|
|
asm volatile("eieio; tlbsync; ptesync": : :"memory");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void _tlbiel_lpid_guest(unsigned long lpid, unsigned long ric)
|
|
|
|
|
{
|
|
|
|
|
int set;
|
|
|
|
|
|
|
|
|
|
VM_BUG_ON(mfspr(SPRN_LPID) != lpid);
|
|
|
|
|
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Flush the first set of the TLB, and if we're doing a RIC_FLUSH_ALL,
|
|
|
|
|
* also flush the entire Page Walk Cache.
|
|
|
|
|
*/
|
|
|
|
|
__tlbiel_lpid_guest(lpid, 0, ric);
|
|
|
|
|
|
|
|
|
|
/* For PWC, only one flush is needed */
|
|
|
|
|
if (ric == RIC_FLUSH_PWC) {
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* For the remaining sets, just flush the TLB */
|
|
|
|
|
for (set = 1; set < POWER9_TLB_SETS_RADIX ; set++)
|
|
|
|
|
__tlbiel_lpid_guest(lpid, set, RIC_FLUSH_TLB);
|
|
|
|
|
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
2018-08-26 21:03:02 -06:00
|
|
|
asm volatile(PPC_INVALIDATE_ERAT : : :"memory");
|
2018-05-08 20:20:18 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
static inline void __tlbiel_va_range(unsigned long start, unsigned long end,
|
|
|
|
|
unsigned long pid, unsigned long page_size,
|
|
|
|
|
unsigned long psize)
|
|
|
|
|
{
|
|
|
|
|
unsigned long addr;
|
|
|
|
|
unsigned long ap = mmu_get_ap(psize);
|
|
|
|
|
|
|
|
|
|
for (addr = start; addr < end; addr += page_size)
|
|
|
|
|
__tlbiel_va(addr, pid, ap, RIC_FLUSH_TLB);
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-07 00:53:05 -07:00
|
|
|
static inline void _tlbiel_va(unsigned long va, unsigned long pid,
|
2017-11-07 00:53:06 -07:00
|
|
|
unsigned long psize, unsigned long ric)
|
2017-11-07 00:53:05 -07:00
|
|
|
{
|
2017-11-07 00:53:06 -07:00
|
|
|
unsigned long ap = mmu_get_ap(psize);
|
|
|
|
|
|
2017-11-07 00:53:05 -07:00
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
__tlbiel_va(va, pid, ap, ric);
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-07 00:53:06 -07:00
|
|
|
static inline void _tlbiel_va_range(unsigned long start, unsigned long end,
|
|
|
|
|
unsigned long pid, unsigned long page_size,
|
2017-11-07 00:53:09 -07:00
|
|
|
unsigned long psize, bool also_pwc)
|
2017-11-07 00:53:06 -07:00
|
|
|
{
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
2017-11-07 00:53:09 -07:00
|
|
|
if (also_pwc)
|
|
|
|
|
__tlbiel_pid(pid, 0, RIC_FLUSH_PWC);
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
__tlbiel_va_range(start, end, pid, page_size, psize);
|
2017-11-07 00:53:06 -07:00
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
}
|
|
|
|
|
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
static inline void __tlbie_va_range(unsigned long start, unsigned long end,
|
|
|
|
|
unsigned long pid, unsigned long page_size,
|
|
|
|
|
unsigned long psize)
|
|
|
|
|
{
|
|
|
|
|
unsigned long addr;
|
|
|
|
|
unsigned long ap = mmu_get_ap(psize);
|
|
|
|
|
|
|
|
|
|
for (addr = start; addr < end; addr += page_size)
|
|
|
|
|
__tlbie_va(addr, pid, ap, RIC_FLUSH_TLB);
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-07 00:53:05 -07:00
|
|
|
static inline void _tlbie_va(unsigned long va, unsigned long pid,
|
2017-11-07 00:53:06 -07:00
|
|
|
unsigned long psize, unsigned long ric)
|
2017-11-07 00:53:05 -07:00
|
|
|
{
|
2017-11-07 00:53:06 -07:00
|
|
|
unsigned long ap = mmu_get_ap(psize);
|
|
|
|
|
|
2017-11-07 00:53:05 -07:00
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
__tlbie_va(va, pid, ap, ric);
|
2018-03-22 22:56:27 -06:00
|
|
|
fixup_tlbie();
|
2017-11-07 00:53:05 -07:00
|
|
|
asm volatile("eieio; tlbsync; ptesync": : :"memory");
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-08 20:20:18 -06:00
|
|
|
static inline void _tlbie_lpid_va(unsigned long va, unsigned long lpid,
|
|
|
|
|
unsigned long psize, unsigned long ric)
|
|
|
|
|
{
|
|
|
|
|
unsigned long ap = mmu_get_ap(psize);
|
|
|
|
|
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
__tlbie_lpid_va(va, lpid, ap, ric);
|
|
|
|
|
fixup_tlbie_lpid(lpid);
|
|
|
|
|
asm volatile("eieio; tlbsync; ptesync": : :"memory");
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-07 00:53:06 -07:00
|
|
|
static inline void _tlbie_va_range(unsigned long start, unsigned long end,
|
|
|
|
|
unsigned long pid, unsigned long page_size,
|
2017-11-07 00:53:09 -07:00
|
|
|
unsigned long psize, bool also_pwc)
|
2017-11-07 00:53:06 -07:00
|
|
|
{
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
2017-11-07 00:53:09 -07:00
|
|
|
if (also_pwc)
|
|
|
|
|
__tlbie_pid(pid, RIC_FLUSH_PWC);
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
__tlbie_va_range(start, end, pid, page_size, psize);
|
2018-03-22 22:56:27 -06:00
|
|
|
fixup_tlbie();
|
2017-11-07 00:53:06 -07:00
|
|
|
asm volatile("eieio; tlbsync; ptesync": : :"memory");
|
|
|
|
|
}
|
2017-11-07 00:53:05 -07:00
|
|
|
|
2016-04-29 07:26:05 -06:00
|
|
|
/*
|
|
|
|
|
* Base TLB flushing operations:
|
|
|
|
|
*
|
|
|
|
|
* - flush_tlb_mm(mm) flushes the specified mm context TLB's
|
|
|
|
|
* - flush_tlb_page(vma, vmaddr) flushes one page
|
|
|
|
|
* - flush_tlb_range(vma, start, end) flushes a range of pages
|
|
|
|
|
* - flush_tlb_kernel_range(start, end) flushes kernel pages
|
|
|
|
|
*
|
|
|
|
|
* - local_* variants of page and mm only apply to the current
|
|
|
|
|
* processor
|
|
|
|
|
*/
|
|
|
|
|
void radix__local_flush_tlb_mm(struct mm_struct *mm)
|
|
|
|
|
{
|
2016-06-02 03:44:48 -06:00
|
|
|
unsigned long pid;
|
2016-04-29 07:26:05 -06:00
|
|
|
|
|
|
|
|
preempt_disable();
|
|
|
|
|
pid = mm->context.id;
|
|
|
|
|
if (pid != MMU_NO_CONTEXT)
|
2017-07-18 22:49:05 -06:00
|
|
|
_tlbiel_pid(pid, RIC_FLUSH_TLB);
|
2016-04-29 07:26:05 -06:00
|
|
|
preempt_enable();
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(radix__local_flush_tlb_mm);
|
|
|
|
|
|
2017-07-18 22:49:05 -06:00
|
|
|
#ifndef CONFIG_SMP
|
2017-09-03 12:15:12 -06:00
|
|
|
void radix__local_flush_all_mm(struct mm_struct *mm)
|
2016-06-08 08:25:51 -06:00
|
|
|
{
|
|
|
|
|
unsigned long pid;
|
|
|
|
|
|
|
|
|
|
preempt_disable();
|
|
|
|
|
pid = mm->context.id;
|
|
|
|
|
if (pid != MMU_NO_CONTEXT)
|
2017-07-18 22:49:05 -06:00
|
|
|
_tlbiel_pid(pid, RIC_FLUSH_ALL);
|
2016-06-08 08:25:51 -06:00
|
|
|
preempt_enable();
|
|
|
|
|
}
|
2017-09-03 12:15:12 -06:00
|
|
|
EXPORT_SYMBOL(radix__local_flush_all_mm);
|
2017-07-18 22:49:05 -06:00
|
|
|
#endif /* CONFIG_SMP */
|
2016-06-08 08:25:51 -06:00
|
|
|
|
2016-07-13 03:36:41 -06:00
|
|
|
void radix__local_flush_tlb_page_psize(struct mm_struct *mm, unsigned long vmaddr,
|
2016-07-13 03:36:42 -06:00
|
|
|
int psize)
|
2016-04-29 07:26:05 -06:00
|
|
|
{
|
2016-06-02 03:44:48 -06:00
|
|
|
unsigned long pid;
|
2016-04-29 07:26:05 -06:00
|
|
|
|
|
|
|
|
preempt_disable();
|
2017-10-16 01:11:00 -06:00
|
|
|
pid = mm->context.id;
|
2016-04-29 07:26:05 -06:00
|
|
|
if (pid != MMU_NO_CONTEXT)
|
2017-11-07 00:53:06 -07:00
|
|
|
_tlbiel_va(vmaddr, pid, psize, RIC_FLUSH_TLB);
|
2016-04-29 07:26:05 -06:00
|
|
|
preempt_enable();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void radix__local_flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr)
|
|
|
|
|
{
|
2016-04-29 07:26:25 -06:00
|
|
|
#ifdef CONFIG_HUGETLB_PAGE
|
|
|
|
|
/* need the return fix for nohash.c */
|
2017-10-16 01:11:00 -06:00
|
|
|
if (is_vm_hugetlb_page(vma))
|
|
|
|
|
return radix__local_flush_hugetlb_page(vma, vmaddr);
|
2016-04-29 07:26:25 -06:00
|
|
|
#endif
|
2017-10-16 01:11:00 -06:00
|
|
|
radix__local_flush_tlb_page_psize(vma->vm_mm, vmaddr, mmu_virtual_psize);
|
2016-04-29 07:26:05 -06:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(radix__local_flush_tlb_page);
|
|
|
|
|
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
static bool mm_is_singlethreaded(struct mm_struct *mm)
|
|
|
|
|
{
|
|
|
|
|
if (atomic_read(&mm->context.copros) > 0)
|
|
|
|
|
return false;
|
|
|
|
|
if (atomic_read(&mm->mm_users) <= 1 && current->mm == mm)
|
|
|
|
|
return true;
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-22 16:29:06 -06:00
|
|
|
static bool mm_needs_flush_escalation(struct mm_struct *mm)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* P9 nest MMU has issues with the page walk cache
|
|
|
|
|
* caching PTEs and not flushing them properly when
|
|
|
|
|
* RIC = 0 for a PID/LPID invalidate
|
|
|
|
|
*/
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
if (atomic_read(&mm->context.copros) > 0)
|
|
|
|
|
return true;
|
|
|
|
|
return false;
|
2018-03-22 16:29:06 -06:00
|
|
|
}
|
|
|
|
|
|
2016-04-29 07:26:05 -06:00
|
|
|
#ifdef CONFIG_SMP
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
static void do_exit_flush_lazy_tlb(void *arg)
|
|
|
|
|
{
|
|
|
|
|
struct mm_struct *mm = arg;
|
|
|
|
|
unsigned long pid = mm->context.id;
|
|
|
|
|
|
|
|
|
|
if (current->mm == mm)
|
|
|
|
|
return; /* Local CPU */
|
|
|
|
|
|
|
|
|
|
if (current->active_mm == mm) {
|
|
|
|
|
/*
|
|
|
|
|
* Must be a kernel thread because sender is single-threaded.
|
|
|
|
|
*/
|
|
|
|
|
BUG_ON(current->mm);
|
|
|
|
|
mmgrab(&init_mm);
|
|
|
|
|
switch_mm(mm, &init_mm, current);
|
|
|
|
|
current->active_mm = &init_mm;
|
|
|
|
|
mmdrop(mm);
|
|
|
|
|
}
|
|
|
|
|
_tlbiel_pid(pid, RIC_FLUSH_ALL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void exit_flush_lazy_tlbs(struct mm_struct *mm)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Would be nice if this was async so it could be run in
|
|
|
|
|
* parallel with our local flush, but generic code does not
|
|
|
|
|
* give a good API for it. Could extend the generic code or
|
|
|
|
|
* make a special powerpc IPI for flushing TLBs.
|
|
|
|
|
* For now it's not too performance critical.
|
|
|
|
|
*/
|
|
|
|
|
smp_call_function_many(mm_cpumask(mm), do_exit_flush_lazy_tlb,
|
|
|
|
|
(void *)mm, 1);
|
|
|
|
|
mm_reset_thread_local(mm);
|
|
|
|
|
}
|
|
|
|
|
|
2016-04-29 07:26:05 -06:00
|
|
|
void radix__flush_tlb_mm(struct mm_struct *mm)
|
|
|
|
|
{
|
2016-06-02 03:44:48 -06:00
|
|
|
unsigned long pid;
|
2016-04-29 07:26:05 -06:00
|
|
|
|
|
|
|
|
pid = mm->context.id;
|
|
|
|
|
if (unlikely(pid == MMU_NO_CONTEXT))
|
2017-10-24 07:06:53 -06:00
|
|
|
return;
|
2016-04-29 07:26:05 -06:00
|
|
|
|
2017-10-24 07:06:53 -06:00
|
|
|
preempt_disable();
|
2018-06-01 04:01:20 -06:00
|
|
|
/*
|
|
|
|
|
* Order loads of mm_cpumask vs previous stores to clear ptes before
|
|
|
|
|
* the invalidate. See barrier in switch_mm_irqs_off
|
|
|
|
|
*/
|
|
|
|
|
smp_mb();
|
2018-03-22 16:29:06 -06:00
|
|
|
if (!mm_is_thread_local(mm)) {
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
if (unlikely(mm_is_singlethreaded(mm))) {
|
|
|
|
|
exit_flush_lazy_tlbs(mm);
|
|
|
|
|
goto local;
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-22 16:29:06 -06:00
|
|
|
if (mm_needs_flush_escalation(mm))
|
|
|
|
|
_tlbie_pid(pid, RIC_FLUSH_ALL);
|
|
|
|
|
else
|
|
|
|
|
_tlbie_pid(pid, RIC_FLUSH_TLB);
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
} else {
|
|
|
|
|
local:
|
2017-07-18 22:49:05 -06:00
|
|
|
_tlbiel_pid(pid, RIC_FLUSH_TLB);
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
}
|
2016-04-29 07:26:05 -06:00
|
|
|
preempt_enable();
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(radix__flush_tlb_mm);
|
|
|
|
|
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
static void __flush_all_mm(struct mm_struct *mm, bool fullmm)
|
2016-06-08 08:25:51 -06:00
|
|
|
{
|
|
|
|
|
unsigned long pid;
|
|
|
|
|
|
|
|
|
|
pid = mm->context.id;
|
|
|
|
|
if (unlikely(pid == MMU_NO_CONTEXT))
|
2017-10-24 07:06:53 -06:00
|
|
|
return;
|
2016-06-08 08:25:51 -06:00
|
|
|
|
2017-10-24 07:06:53 -06:00
|
|
|
preempt_disable();
|
2018-06-01 04:01:20 -06:00
|
|
|
smp_mb(); /* see radix__flush_tlb_mm */
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
if (!mm_is_thread_local(mm)) {
|
|
|
|
|
if (unlikely(mm_is_singlethreaded(mm))) {
|
|
|
|
|
if (!fullmm) {
|
|
|
|
|
exit_flush_lazy_tlbs(mm);
|
|
|
|
|
goto local;
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-07-18 22:49:05 -06:00
|
|
|
_tlbie_pid(pid, RIC_FLUSH_ALL);
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
} else {
|
|
|
|
|
local:
|
2017-07-18 22:49:05 -06:00
|
|
|
_tlbiel_pid(pid, RIC_FLUSH_ALL);
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
}
|
2016-06-08 08:25:51 -06:00
|
|
|
preempt_enable();
|
|
|
|
|
}
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
void radix__flush_all_mm(struct mm_struct *mm)
|
|
|
|
|
{
|
|
|
|
|
__flush_all_mm(mm, false);
|
|
|
|
|
}
|
2017-09-03 12:15:12 -06:00
|
|
|
EXPORT_SYMBOL(radix__flush_all_mm);
|
2017-07-18 22:49:05 -06:00
|
|
|
|
|
|
|
|
void radix__flush_tlb_pwc(struct mmu_gather *tlb, unsigned long addr)
|
|
|
|
|
{
|
|
|
|
|
tlb->need_flush_all = 1;
|
|
|
|
|
}
|
2016-06-08 08:25:51 -06:00
|
|
|
EXPORT_SYMBOL(radix__flush_tlb_pwc);
|
|
|
|
|
|
2016-07-13 03:36:41 -06:00
|
|
|
void radix__flush_tlb_page_psize(struct mm_struct *mm, unsigned long vmaddr,
|
2016-07-13 03:36:42 -06:00
|
|
|
int psize)
|
2016-04-29 07:26:05 -06:00
|
|
|
{
|
2016-06-02 03:44:48 -06:00
|
|
|
unsigned long pid;
|
2016-04-29 07:26:05 -06:00
|
|
|
|
2017-10-16 01:11:00 -06:00
|
|
|
pid = mm->context.id;
|
2016-04-29 07:26:05 -06:00
|
|
|
if (unlikely(pid == MMU_NO_CONTEXT))
|
2017-10-24 07:06:53 -06:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
preempt_disable();
|
2018-06-01 04:01:20 -06:00
|
|
|
smp_mb(); /* see radix__flush_tlb_mm */
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
if (!mm_is_thread_local(mm)) {
|
|
|
|
|
if (unlikely(mm_is_singlethreaded(mm))) {
|
|
|
|
|
exit_flush_lazy_tlbs(mm);
|
|
|
|
|
goto local;
|
|
|
|
|
}
|
2017-11-07 00:53:06 -07:00
|
|
|
_tlbie_va(vmaddr, pid, psize, RIC_FLUSH_TLB);
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
} else {
|
|
|
|
|
local:
|
2017-11-07 00:53:06 -07:00
|
|
|
_tlbiel_va(vmaddr, pid, psize, RIC_FLUSH_TLB);
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
}
|
2016-04-29 07:26:05 -06:00
|
|
|
preempt_enable();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void radix__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr)
|
|
|
|
|
{
|
2016-04-29 07:26:25 -06:00
|
|
|
#ifdef CONFIG_HUGETLB_PAGE
|
2017-10-16 01:11:00 -06:00
|
|
|
if (is_vm_hugetlb_page(vma))
|
|
|
|
|
return radix__flush_hugetlb_page(vma, vmaddr);
|
2016-04-29 07:26:25 -06:00
|
|
|
#endif
|
2017-10-16 01:11:00 -06:00
|
|
|
radix__flush_tlb_page_psize(vma->vm_mm, vmaddr, mmu_virtual_psize);
|
2016-04-29 07:26:05 -06:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(radix__flush_tlb_page);
|
|
|
|
|
|
2017-07-18 22:49:05 -06:00
|
|
|
#else /* CONFIG_SMP */
|
|
|
|
|
#define radix__flush_all_mm radix__local_flush_all_mm
|
2016-04-29 07:26:05 -06:00
|
|
|
#endif /* CONFIG_SMP */
|
|
|
|
|
|
2019-06-19 22:12:01 -06:00
|
|
|
/*
|
|
|
|
|
* If kernel TLBIs ever become local rather than global, then
|
|
|
|
|
* drivers/misc/ocxl/link.c:ocxl_link_add_pe will need some work, as it
|
|
|
|
|
* assumes kernel TLBIs are global.
|
|
|
|
|
*/
|
2016-04-29 07:26:05 -06:00
|
|
|
void radix__flush_tlb_kernel_range(unsigned long start, unsigned long end)
|
|
|
|
|
{
|
2016-06-08 08:25:50 -06:00
|
|
|
_tlbie_pid(0, RIC_FLUSH_ALL);
|
2016-04-29 07:26:05 -06:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(radix__flush_tlb_kernel_range);
|
|
|
|
|
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
#define TLB_FLUSH_ALL -1UL
|
|
|
|
|
|
2016-04-29 07:26:05 -06:00
|
|
|
/*
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
* Number of pages above which we invalidate the entire PID rather than
|
|
|
|
|
* flush individual pages, for local and global flushes respectively.
|
|
|
|
|
*
|
|
|
|
|
* tlbie goes out to the interconnect and individual ops are more costly.
|
|
|
|
|
* It also does not iterate over sets like the local tlbiel variant when
|
|
|
|
|
* invalidating a full PID, so it has a far lower threshold to change from
|
|
|
|
|
* individual page flushes to full-pid flushes.
|
2016-04-29 07:26:05 -06:00
|
|
|
*/
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
static unsigned long tlb_single_page_flush_ceiling __read_mostly = 33;
|
powerpc/64s/radix: Introduce local single page ceiling for TLB range flush
The single page flush ceiling is the cut-off point at which we switch
from invalidating individual pages, to invalidating the entire process
address space in response to a range flush.
Introduce a local variant of this heuristic because local and global
tlbie have significantly different properties:
- Local tlbiel requires 128 instructions to invalidate a PID, global
tlbie only 1 instruction.
- Global tlbie instructions are expensive broadcast operations.
The local ceiling has been made much higher, 2x the number of
instructions required to invalidate the entire PID (i.e., 256 pages).
Time to mprotect N pages of memory (after mmap, touch), local invalidate:
N 32 34 64 128 256 512
vanilla 7.4us 9.0us 14.6us 26.4us 50.2us 98.3us
patched 7.4us 7.8us 13.8us 26.4us 51.9us 98.3us
The behaviour of both is identical at N=32 and N=512. Between there,
the vanilla kernel does a PID invalidate and the patched kernel does
a va range invalidate.
At N=128, these require the same number of tlbiel instructions, so
the patched version can be sen to be cheaper when < 128, and more
expensive when > 128. However this does not well capture the cost
of invalidated TLB.
The additional cost at 256 pages does not seem prohibitive. It may
be the case that increasing the limit further would continue to be
beneficial to avoid invalidating all of the process's TLB entries.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:08 -07:00
|
|
|
static unsigned long tlb_local_single_page_flush_ceiling __read_mostly = POWER9_TLB_SETS_RADIX * 2;
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
|
2018-06-14 19:38:37 -06:00
|
|
|
static inline void __radix__flush_tlb_range(struct mm_struct *mm,
|
|
|
|
|
unsigned long start, unsigned long end,
|
|
|
|
|
bool flush_all_sizes)
|
2016-04-29 07:26:05 -06:00
|
|
|
|
|
|
|
|
{
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
unsigned long pid;
|
|
|
|
|
unsigned int page_shift = mmu_psize_defs[mmu_virtual_psize].shift;
|
|
|
|
|
unsigned long page_size = 1UL << page_shift;
|
|
|
|
|
unsigned long nr_pages = (end - start) >> page_shift;
|
|
|
|
|
bool local, full;
|
2017-07-18 22:49:05 -06:00
|
|
|
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
pid = mm->context.id;
|
|
|
|
|
if (unlikely(pid == MMU_NO_CONTEXT))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
preempt_disable();
|
2018-06-01 04:01:20 -06:00
|
|
|
smp_mb(); /* see radix__flush_tlb_mm */
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
if (!mm_is_thread_local(mm)) {
|
|
|
|
|
if (unlikely(mm_is_singlethreaded(mm))) {
|
|
|
|
|
if (end != TLB_FLUSH_ALL) {
|
|
|
|
|
exit_flush_lazy_tlbs(mm);
|
|
|
|
|
goto is_local;
|
|
|
|
|
}
|
|
|
|
|
}
|
powerpc/64s/radix: Introduce local single page ceiling for TLB range flush
The single page flush ceiling is the cut-off point at which we switch
from invalidating individual pages, to invalidating the entire process
address space in response to a range flush.
Introduce a local variant of this heuristic because local and global
tlbie have significantly different properties:
- Local tlbiel requires 128 instructions to invalidate a PID, global
tlbie only 1 instruction.
- Global tlbie instructions are expensive broadcast operations.
The local ceiling has been made much higher, 2x the number of
instructions required to invalidate the entire PID (i.e., 256 pages).
Time to mprotect N pages of memory (after mmap, touch), local invalidate:
N 32 34 64 128 256 512
vanilla 7.4us 9.0us 14.6us 26.4us 50.2us 98.3us
patched 7.4us 7.8us 13.8us 26.4us 51.9us 98.3us
The behaviour of both is identical at N=32 and N=512. Between there,
the vanilla kernel does a PID invalidate and the patched kernel does
a va range invalidate.
At N=128, these require the same number of tlbiel instructions, so
the patched version can be sen to be cheaper when < 128, and more
expensive when > 128. However this does not well capture the cost
of invalidated TLB.
The additional cost at 256 pages does not seem prohibitive. It may
be the case that increasing the limit further would continue to be
beneficial to avoid invalidating all of the process's TLB entries.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:08 -07:00
|
|
|
local = false;
|
|
|
|
|
full = (end == TLB_FLUSH_ALL ||
|
|
|
|
|
nr_pages > tlb_single_page_flush_ceiling);
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
} else {
|
|
|
|
|
is_local:
|
|
|
|
|
local = true;
|
|
|
|
|
full = (end == TLB_FLUSH_ALL ||
|
|
|
|
|
nr_pages > tlb_local_single_page_flush_ceiling);
|
powerpc/64s/radix: Introduce local single page ceiling for TLB range flush
The single page flush ceiling is the cut-off point at which we switch
from invalidating individual pages, to invalidating the entire process
address space in response to a range flush.
Introduce a local variant of this heuristic because local and global
tlbie have significantly different properties:
- Local tlbiel requires 128 instructions to invalidate a PID, global
tlbie only 1 instruction.
- Global tlbie instructions are expensive broadcast operations.
The local ceiling has been made much higher, 2x the number of
instructions required to invalidate the entire PID (i.e., 256 pages).
Time to mprotect N pages of memory (after mmap, touch), local invalidate:
N 32 34 64 128 256 512
vanilla 7.4us 9.0us 14.6us 26.4us 50.2us 98.3us
patched 7.4us 7.8us 13.8us 26.4us 51.9us 98.3us
The behaviour of both is identical at N=32 and N=512. Between there,
the vanilla kernel does a PID invalidate and the patched kernel does
a va range invalidate.
At N=128, these require the same number of tlbiel instructions, so
the patched version can be sen to be cheaper when < 128, and more
expensive when > 128. However this does not well capture the cost
of invalidated TLB.
The additional cost at 256 pages does not seem prohibitive. It may
be the case that increasing the limit further would continue to be
beneficial to avoid invalidating all of the process's TLB entries.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:08 -07:00
|
|
|
}
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
|
|
|
|
|
if (full) {
|
2018-03-22 16:29:06 -06:00
|
|
|
if (local) {
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
_tlbiel_pid(pid, RIC_FLUSH_TLB);
|
2018-03-22 16:29:06 -06:00
|
|
|
} else {
|
|
|
|
|
if (mm_needs_flush_escalation(mm))
|
|
|
|
|
_tlbie_pid(pid, RIC_FLUSH_ALL);
|
|
|
|
|
else
|
|
|
|
|
_tlbie_pid(pid, RIC_FLUSH_TLB);
|
|
|
|
|
}
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
} else {
|
2018-06-14 19:38:37 -06:00
|
|
|
bool hflush = flush_all_sizes;
|
|
|
|
|
bool gflush = flush_all_sizes;
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
unsigned long hstart, hend;
|
2018-06-14 19:38:37 -06:00
|
|
|
unsigned long gstart, gend;
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
|
2018-06-14 19:38:37 -06:00
|
|
|
if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
hflush = true;
|
2018-06-14 19:38:37 -06:00
|
|
|
|
|
|
|
|
if (hflush) {
|
|
|
|
|
hstart = (start + PMD_SIZE - 1) & PMD_MASK;
|
|
|
|
|
hend = end & PMD_MASK;
|
|
|
|
|
if (hstart == hend)
|
|
|
|
|
hflush = false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (gflush) {
|
|
|
|
|
gstart = (start + PUD_SIZE - 1) & PUD_MASK;
|
|
|
|
|
gend = end & PUD_MASK;
|
|
|
|
|
if (gstart == gend)
|
|
|
|
|
gflush = false;
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
if (local) {
|
|
|
|
|
__tlbiel_va_range(start, end, pid, page_size, mmu_virtual_psize);
|
|
|
|
|
if (hflush)
|
|
|
|
|
__tlbiel_va_range(hstart, hend, pid,
|
2018-06-14 19:38:37 -06:00
|
|
|
PMD_SIZE, MMU_PAGE_2M);
|
|
|
|
|
if (gflush)
|
|
|
|
|
__tlbiel_va_range(gstart, gend, pid,
|
|
|
|
|
PUD_SIZE, MMU_PAGE_1G);
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
} else {
|
|
|
|
|
__tlbie_va_range(start, end, pid, page_size, mmu_virtual_psize);
|
|
|
|
|
if (hflush)
|
|
|
|
|
__tlbie_va_range(hstart, hend, pid,
|
2018-06-14 19:38:37 -06:00
|
|
|
PMD_SIZE, MMU_PAGE_2M);
|
|
|
|
|
if (gflush)
|
|
|
|
|
__tlbie_va_range(gstart, gend, pid,
|
|
|
|
|
PUD_SIZE, MMU_PAGE_1G);
|
2018-03-22 22:56:27 -06:00
|
|
|
fixup_tlbie();
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
asm volatile("eieio; tlbsync; ptesync": : :"memory");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
preempt_enable();
|
2016-04-29 07:26:05 -06:00
|
|
|
}
|
2018-06-14 19:38:37 -06:00
|
|
|
|
|
|
|
|
void radix__flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
|
|
|
|
|
unsigned long end)
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
#ifdef CONFIG_HUGETLB_PAGE
|
|
|
|
|
if (is_vm_hugetlb_page(vma))
|
|
|
|
|
return radix__flush_hugetlb_tlb_range(vma, start, end);
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
__radix__flush_tlb_range(vma->vm_mm, start, end, false);
|
|
|
|
|
}
|
2016-04-29 07:26:05 -06:00
|
|
|
EXPORT_SYMBOL(radix__flush_tlb_range);
|
|
|
|
|
|
2016-07-13 03:35:29 -06:00
|
|
|
static int radix_get_mmu_psize(int page_size)
|
|
|
|
|
{
|
|
|
|
|
int psize;
|
|
|
|
|
|
|
|
|
|
if (page_size == (1UL << mmu_psize_defs[mmu_virtual_psize].shift))
|
|
|
|
|
psize = mmu_virtual_psize;
|
|
|
|
|
else if (page_size == (1UL << mmu_psize_defs[MMU_PAGE_2M].shift))
|
|
|
|
|
psize = MMU_PAGE_2M;
|
|
|
|
|
else if (page_size == (1UL << mmu_psize_defs[MMU_PAGE_1G].shift))
|
|
|
|
|
psize = MMU_PAGE_1G;
|
|
|
|
|
else
|
|
|
|
|
return -1;
|
|
|
|
|
return psize;
|
|
|
|
|
}
|
2016-04-29 07:26:05 -06:00
|
|
|
|
2018-05-08 20:20:18 -06:00
|
|
|
/*
|
|
|
|
|
* Flush partition scoped LPID address translation for all CPUs.
|
|
|
|
|
*/
|
|
|
|
|
void radix__flush_tlb_lpid_page(unsigned int lpid,
|
|
|
|
|
unsigned long addr,
|
|
|
|
|
unsigned long page_size)
|
|
|
|
|
{
|
|
|
|
|
int psize = radix_get_mmu_psize(page_size);
|
|
|
|
|
|
|
|
|
|
_tlbie_lpid_va(addr, lpid, psize, RIC_FLUSH_TLB);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(radix__flush_tlb_lpid_page);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Flush partition scoped PWC from LPID for all CPUs.
|
|
|
|
|
*/
|
|
|
|
|
void radix__flush_pwc_lpid(unsigned int lpid)
|
|
|
|
|
{
|
|
|
|
|
_tlbie_lpid(lpid, RIC_FLUSH_PWC);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(radix__flush_pwc_lpid);
|
|
|
|
|
|
2018-10-07 23:31:07 -06:00
|
|
|
/*
|
|
|
|
|
* Flush partition scoped translations from LPID (=LPIDR)
|
|
|
|
|
*/
|
|
|
|
|
void radix__flush_tlb_lpid(unsigned int lpid)
|
|
|
|
|
{
|
|
|
|
|
_tlbie_lpid(lpid, RIC_FLUSH_ALL);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(radix__flush_tlb_lpid);
|
|
|
|
|
|
2018-05-08 20:20:18 -06:00
|
|
|
/*
|
|
|
|
|
* Flush partition scoped translations from LPID (=LPIDR)
|
|
|
|
|
*/
|
|
|
|
|
void radix__local_flush_tlb_lpid(unsigned int lpid)
|
|
|
|
|
{
|
|
|
|
|
_tlbiel_lpid(lpid, RIC_FLUSH_ALL);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(radix__local_flush_tlb_lpid);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Flush process scoped translations from LPID (=LPIDR).
|
|
|
|
|
* Important difference, the guest normally manages its own translations,
|
|
|
|
|
* but some cases e.g., vCPU CPU migration require KVM to flush.
|
|
|
|
|
*/
|
|
|
|
|
void radix__local_flush_tlb_lpid_guest(unsigned int lpid)
|
|
|
|
|
{
|
|
|
|
|
_tlbiel_lpid_guest(lpid, RIC_FLUSH_ALL);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(radix__local_flush_tlb_lpid_guest);
|
|
|
|
|
|
|
|
|
|
|
2017-11-07 00:53:09 -07:00
|
|
|
static void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long start,
|
|
|
|
|
unsigned long end, int psize);
|
|
|
|
|
|
2016-04-29 07:26:05 -06:00
|
|
|
void radix__tlb_flush(struct mmu_gather *tlb)
|
|
|
|
|
{
|
2016-07-13 03:36:35 -06:00
|
|
|
int psize = 0;
|
2016-04-29 07:26:05 -06:00
|
|
|
struct mm_struct *mm = tlb->mm;
|
2016-07-13 03:36:35 -06:00
|
|
|
int page_size = tlb->page_size;
|
2018-06-14 19:38:37 -06:00
|
|
|
unsigned long start = tlb->start;
|
|
|
|
|
unsigned long end = tlb->end;
|
2016-07-13 03:36:35 -06:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* if page size is not something we understand, do a full mm flush
|
2017-10-24 07:06:54 -06:00
|
|
|
*
|
|
|
|
|
* A "fullmm" flush must always do a flush_all_mm (RIC=2) flush
|
|
|
|
|
* that flushes the process table entry cache upon process teardown.
|
|
|
|
|
* See the comment for radix in arch_exit_mmap().
|
2016-07-13 03:36:35 -06:00
|
|
|
*/
|
2017-11-07 00:53:09 -07:00
|
|
|
if (tlb->fullmm) {
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
__flush_all_mm(mm, true);
|
2018-06-14 19:38:37 -06:00
|
|
|
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_HUGETLB_PAGE)
|
|
|
|
|
} else if (mm_tlb_flush_nested(mm)) {
|
|
|
|
|
/*
|
|
|
|
|
* If there is a concurrent invalidation that is clearing ptes,
|
|
|
|
|
* then it's possible this invalidation will miss one of those
|
|
|
|
|
* cleared ptes and miss flushing the TLB. If this invalidate
|
|
|
|
|
* returns before the other one flushes TLBs, that can result
|
|
|
|
|
* in it returning while there are still valid TLBs inside the
|
|
|
|
|
* range to be invalidated.
|
|
|
|
|
*
|
|
|
|
|
* See mm/memory.c:tlb_finish_mmu() for more details.
|
|
|
|
|
*
|
|
|
|
|
* The solution to this is ensure the entire range is always
|
|
|
|
|
* flushed here. The problem for powerpc is that the flushes
|
|
|
|
|
* are page size specific, so this "forced flush" would not
|
|
|
|
|
* do the right thing if there are a mix of page sizes in
|
|
|
|
|
* the range to be invalidated. So use __flush_tlb_range
|
|
|
|
|
* which invalidates all possible page sizes in the range.
|
|
|
|
|
*
|
|
|
|
|
* PWC flush probably is not be required because the core code
|
|
|
|
|
* shouldn't free page tables in this path, but accounting
|
|
|
|
|
* for the possibility makes us a bit more robust.
|
|
|
|
|
*
|
|
|
|
|
* need_flush_all is an uncommon case because page table
|
|
|
|
|
* teardown should be done with exclusive locks held (but
|
|
|
|
|
* after locks are dropped another invalidate could come
|
|
|
|
|
* in), it could be optimized further if necessary.
|
|
|
|
|
*/
|
|
|
|
|
if (!tlb->need_flush_all)
|
|
|
|
|
__radix__flush_tlb_range(mm, start, end, true);
|
|
|
|
|
else
|
|
|
|
|
radix__flush_all_mm(mm);
|
|
|
|
|
#endif
|
2017-11-07 00:53:09 -07:00
|
|
|
} else if ( (psize = radix_get_mmu_psize(page_size)) == -1) {
|
|
|
|
|
if (!tlb->need_flush_all)
|
|
|
|
|
radix__flush_tlb_mm(mm);
|
|
|
|
|
else
|
|
|
|
|
radix__flush_all_mm(mm);
|
|
|
|
|
} else {
|
|
|
|
|
if (!tlb->need_flush_all)
|
|
|
|
|
radix__flush_tlb_range_psize(mm, start, end, psize);
|
|
|
|
|
else
|
|
|
|
|
radix__flush_tlb_pwc_range_psize(mm, start, end, psize);
|
|
|
|
|
}
|
|
|
|
|
tlb->need_flush_all = 0;
|
2016-07-13 03:36:35 -06:00
|
|
|
}
|
|
|
|
|
|
2019-05-14 16:42:17 -06:00
|
|
|
static __always_inline void __radix__flush_tlb_range_psize(struct mm_struct *mm,
|
2017-11-07 00:53:09 -07:00
|
|
|
unsigned long start, unsigned long end,
|
|
|
|
|
int psize, bool also_pwc)
|
2016-07-13 03:36:35 -06:00
|
|
|
{
|
|
|
|
|
unsigned long pid;
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
unsigned int page_shift = mmu_psize_defs[psize].shift;
|
|
|
|
|
unsigned long page_size = 1UL << page_shift;
|
|
|
|
|
unsigned long nr_pages = (end - start) >> page_shift;
|
|
|
|
|
bool local, full;
|
2016-07-13 03:36:35 -06:00
|
|
|
|
2017-10-16 01:11:00 -06:00
|
|
|
pid = mm->context.id;
|
2016-07-13 03:36:35 -06:00
|
|
|
if (unlikely(pid == MMU_NO_CONTEXT))
|
2017-10-24 07:06:53 -06:00
|
|
|
return;
|
2016-07-13 03:36:35 -06:00
|
|
|
|
2017-10-24 07:06:53 -06:00
|
|
|
preempt_disable();
|
2018-06-01 04:01:20 -06:00
|
|
|
smp_mb(); /* see radix__flush_tlb_mm */
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
if (!mm_is_thread_local(mm)) {
|
|
|
|
|
if (unlikely(mm_is_singlethreaded(mm))) {
|
|
|
|
|
if (end != TLB_FLUSH_ALL) {
|
|
|
|
|
exit_flush_lazy_tlbs(mm);
|
|
|
|
|
goto is_local;
|
|
|
|
|
}
|
|
|
|
|
}
|
powerpc/64s/radix: Introduce local single page ceiling for TLB range flush
The single page flush ceiling is the cut-off point at which we switch
from invalidating individual pages, to invalidating the entire process
address space in response to a range flush.
Introduce a local variant of this heuristic because local and global
tlbie have significantly different properties:
- Local tlbiel requires 128 instructions to invalidate a PID, global
tlbie only 1 instruction.
- Global tlbie instructions are expensive broadcast operations.
The local ceiling has been made much higher, 2x the number of
instructions required to invalidate the entire PID (i.e., 256 pages).
Time to mprotect N pages of memory (after mmap, touch), local invalidate:
N 32 34 64 128 256 512
vanilla 7.4us 9.0us 14.6us 26.4us 50.2us 98.3us
patched 7.4us 7.8us 13.8us 26.4us 51.9us 98.3us
The behaviour of both is identical at N=32 and N=512. Between there,
the vanilla kernel does a PID invalidate and the patched kernel does
a va range invalidate.
At N=128, these require the same number of tlbiel instructions, so
the patched version can be sen to be cheaper when < 128, and more
expensive when > 128. However this does not well capture the cost
of invalidated TLB.
The additional cost at 256 pages does not seem prohibitive. It may
be the case that increasing the limit further would continue to be
beneficial to avoid invalidating all of the process's TLB entries.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:08 -07:00
|
|
|
local = false;
|
|
|
|
|
full = (end == TLB_FLUSH_ALL ||
|
|
|
|
|
nr_pages > tlb_single_page_flush_ceiling);
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
} else {
|
|
|
|
|
is_local:
|
|
|
|
|
local = true;
|
|
|
|
|
full = (end == TLB_FLUSH_ALL ||
|
|
|
|
|
nr_pages > tlb_local_single_page_flush_ceiling);
|
powerpc/64s/radix: Introduce local single page ceiling for TLB range flush
The single page flush ceiling is the cut-off point at which we switch
from invalidating individual pages, to invalidating the entire process
address space in response to a range flush.
Introduce a local variant of this heuristic because local and global
tlbie have significantly different properties:
- Local tlbiel requires 128 instructions to invalidate a PID, global
tlbie only 1 instruction.
- Global tlbie instructions are expensive broadcast operations.
The local ceiling has been made much higher, 2x the number of
instructions required to invalidate the entire PID (i.e., 256 pages).
Time to mprotect N pages of memory (after mmap, touch), local invalidate:
N 32 34 64 128 256 512
vanilla 7.4us 9.0us 14.6us 26.4us 50.2us 98.3us
patched 7.4us 7.8us 13.8us 26.4us 51.9us 98.3us
The behaviour of both is identical at N=32 and N=512. Between there,
the vanilla kernel does a PID invalidate and the patched kernel does
a va range invalidate.
At N=128, these require the same number of tlbiel instructions, so
the patched version can be sen to be cheaper when < 128, and more
expensive when > 128. However this does not well capture the cost
of invalidated TLB.
The additional cost at 256 pages does not seem prohibitive. It may
be the case that increasing the limit further would continue to be
beneficial to avoid invalidating all of the process's TLB entries.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:08 -07:00
|
|
|
}
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
|
|
|
|
|
if (full) {
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
if (local) {
|
2017-11-07 00:53:09 -07:00
|
|
|
_tlbiel_pid(pid, also_pwc ? RIC_FLUSH_ALL : RIC_FLUSH_TLB);
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
} else {
|
|
|
|
|
if (mm_needs_flush_escalation(mm))
|
|
|
|
|
also_pwc = true;
|
|
|
|
|
|
|
|
|
|
_tlbie_pid(pid, also_pwc ? RIC_FLUSH_ALL : RIC_FLUSH_TLB);
|
|
|
|
|
}
|
2017-10-24 07:06:53 -06:00
|
|
|
} else {
|
2017-11-07 00:53:05 -07:00
|
|
|
if (local)
|
2017-11-07 00:53:09 -07:00
|
|
|
_tlbiel_va_range(start, end, pid, page_size, psize, also_pwc);
|
2017-11-07 00:53:05 -07:00
|
|
|
else
|
2017-11-07 00:53:09 -07:00
|
|
|
_tlbie_va_range(start, end, pid, page_size, psize, also_pwc);
|
2016-07-13 03:36:35 -06:00
|
|
|
}
|
|
|
|
|
preempt_enable();
|
2016-04-29 07:26:05 -06:00
|
|
|
}
|
2016-07-13 03:35:29 -06:00
|
|
|
|
2017-11-07 00:53:09 -07:00
|
|
|
void radix__flush_tlb_range_psize(struct mm_struct *mm, unsigned long start,
|
|
|
|
|
unsigned long end, int psize)
|
|
|
|
|
{
|
|
|
|
|
return __radix__flush_tlb_range_psize(mm, start, end, psize, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long start,
|
|
|
|
|
unsigned long end, int psize)
|
|
|
|
|
{
|
|
|
|
|
__radix__flush_tlb_range_psize(mm, start, end, psize, true);
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-18 22:49:06 -06:00
|
|
|
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
|
|
|
|
|
void radix__flush_tlb_collapsed_pmd(struct mm_struct *mm, unsigned long addr)
|
|
|
|
|
{
|
|
|
|
|
unsigned long pid, end;
|
|
|
|
|
|
2017-10-16 01:11:00 -06:00
|
|
|
pid = mm->context.id;
|
2017-07-18 22:49:06 -06:00
|
|
|
if (unlikely(pid == MMU_NO_CONTEXT))
|
2017-10-24 07:06:53 -06:00
|
|
|
return;
|
2017-07-18 22:49:06 -06:00
|
|
|
|
|
|
|
|
/* 4k page size, just blow the world */
|
|
|
|
|
if (PAGE_SIZE == 0x1000) {
|
|
|
|
|
radix__flush_all_mm(mm);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
end = addr + HPAGE_PMD_SIZE;
|
|
|
|
|
|
|
|
|
|
/* Otherwise first do the PWC, then iterate the pages. */
|
2017-10-24 07:06:53 -06:00
|
|
|
preempt_disable();
|
2018-06-01 04:01:20 -06:00
|
|
|
smp_mb(); /* see radix__flush_tlb_mm */
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
if (!mm_is_thread_local(mm)) {
|
|
|
|
|
if (unlikely(mm_is_singlethreaded(mm))) {
|
|
|
|
|
exit_flush_lazy_tlbs(mm);
|
|
|
|
|
goto local;
|
|
|
|
|
}
|
2017-11-07 00:53:09 -07:00
|
|
|
_tlbie_va_range(addr, end, pid, PAGE_SIZE, mmu_virtual_psize, true);
|
powerpc/64s/radix: flush remote CPUs out of single-threaded mm_cpumask
When a single-threaded process has a non-local mm_cpumask, try to use
that point to flush the TLBs out of other CPUs in the cpumask.
An IPI is used for clearing remote CPUs for a few reasons:
- An IPI can end lazy TLB use of the mm, which is required to prevent
TLB entries being created on the remote CPU. The alternative is to
drop lazy TLB switching completely, which costs 7.5% in a context
switch ping-pong test betwee a process and kernel idle thread.
- An IPI can have remote CPUs flush the entire PID, but the local CPU
can flush a specific VA. tlbie would require over-flushing of the
local CPU (where the process is running).
- A single threaded process that is migrated to a different CPU is
likely to have a relatively small mm_cpumask, so IPI is reasonable.
No other thread can concurrently switch to this mm, because it must
have been given a reference to mm_users by the current thread before it
can use_mm. mm_users can be asynchronously incremented (by
mm_activate or mmget_not_zero), but those users must use remote mm
access and can't use_mm or access user address space. Existing code
makes the this assumption already, for example sparc64 has reset
mm_cpumask using this condition since the start of history, see
arch/sparc/kernel/smp_64.c.
This reduces tlbies for a kernel compile workload from 0.90M to 0.12M,
tlbiels are increased significantly due to the PID flushing for the
cleaning up remote CPUs, and increased local flushes (PID flushes take
128 tlbiels vs 1 tlbie).
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-06-01 04:01:21 -06:00
|
|
|
} else {
|
|
|
|
|
local:
|
|
|
|
|
_tlbiel_va_range(addr, end, pid, PAGE_SIZE, mmu_virtual_psize, true);
|
powerpc/64s/radix: Optimize flush_tlb_range
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page size (regular and THP). The second flush has an order of matnitude
fewer tlbie instructions than the first, so it is a relatively small
additional cost.
There is still room for improvement here with some changes to generic
APIs, particularly if there are mostly THP pages to be invalidated,
the small page flushes could be reduced.
Time to mprotect 1 page of memory (after mmap, touch):
vanilla 2.9us 1.8us
patched 1.2us 1.6us
Time to mprotect 30 pages of memory (after mmap, touch):
vanilla 8.2us 7.2us
patched 6.9us 17.9us
Time to mprotect 34 pages of memory (after mmap, touch):
vanilla 9.1us 8.0us
patched 9.0us 8.0us
34 pages is the point at which the invalidation switches from va
to entire PID, which tlbie can do in a single instruction. This is
why in the case of 30 pages, the new code runs slower for this test.
This is a deliberate tradeoff already present in the unmap and THP
promotion code, the idea is that the benefit from avoiding flushing
entire TLB for this PID on all threads in the system.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-07 00:53:07 -07:00
|
|
|
}
|
2017-11-07 00:53:05 -07:00
|
|
|
|
2017-07-18 22:49:06 -06:00
|
|
|
preempt_enable();
|
|
|
|
|
}
|
|
|
|
|
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
|
|
|
|
|
|
2016-07-13 03:36:40 -06:00
|
|
|
void radix__flush_pmd_tlb_range(struct vm_area_struct *vma,
|
|
|
|
|
unsigned long start, unsigned long end)
|
|
|
|
|
{
|
|
|
|
|
radix__flush_tlb_range_psize(vma->vm_mm, start, end, MMU_PAGE_2M);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(radix__flush_pmd_tlb_range);
|
2016-08-23 04:57:48 -06:00
|
|
|
|
|
|
|
|
void radix__flush_tlb_all(void)
|
|
|
|
|
{
|
|
|
|
|
unsigned long rb,prs,r,rs;
|
|
|
|
|
unsigned long ric = RIC_FLUSH_ALL;
|
|
|
|
|
|
|
|
|
|
rb = 0x3 << PPC_BITLSHIFT(53); /* IS = 3 */
|
|
|
|
|
prs = 0; /* partition scoped */
|
2018-01-31 22:07:25 -07:00
|
|
|
r = 1; /* radix format */
|
2016-08-23 04:57:48 -06:00
|
|
|
rs = 1 & ((1UL << 32) - 1); /* any LPID value to flush guest mappings */
|
|
|
|
|
|
|
|
|
|
asm volatile("ptesync": : :"memory");
|
|
|
|
|
/*
|
|
|
|
|
* now flush guest entries by passing PRS = 1 and LPID != 0
|
|
|
|
|
*/
|
|
|
|
|
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r"(rb), "i"(r), "i"(1), "i"(ric), "r"(rs) : "memory");
|
|
|
|
|
/*
|
|
|
|
|
* now flush host entires by passing PRS = 0 and LPID == 0
|
|
|
|
|
*/
|
|
|
|
|
asm volatile(PPC_TLBIE_5(%0, %4, %3, %2, %1)
|
|
|
|
|
: : "r"(rb), "i"(r), "i"(prs), "i"(ric), "r"(0) : "memory");
|
|
|
|
|
asm volatile("eieio; tlbsync; ptesync": : :"memory");
|
|
|
|
|
}
|
2016-11-27 23:17:01 -07:00
|
|
|
|
powerpc/mm/radix: Workaround prefetch issue with KVM
There's a somewhat architectural issue with Radix MMU and KVM.
When coming out of a guest with AIL (Alternate Interrupt Location, ie,
MMU enabled), we start executing hypervisor code with the PID register
still containing whatever the guest has been using.
The problem is that the CPU can (and will) then start prefetching or
speculatively load from whatever host context has that same PID (if
any), thus bringing translations for that context into the TLB, which
Linux doesn't know about.
This can cause stale translations and subsequent crashes.
Fixing this in a way that is neither racy nor a huge performance
impact is difficult. We could just make the host invalidations always
use broadcast forms but that would hurt single threaded programs for
example.
We chose to fix it instead by partitioning the PID space between guest
and host. This is possible because today Linux only use 19 out of the
20 bits of PID space, so existing guests will work if we make the host
use the top half of the 20 bits space.
We additionally add support for a property to indicate to Linux the
size of the PID register which will be useful if we eventually have
processors with a larger PID space available.
There is still an issue with malicious guests purposefully setting the
PID register to a value in the hosts PID range. Hopefully future HW
can prevent that, but in the meantime, we handle it with a pair of
kludges:
- On the way out of a guest, before we clear the current VCPU in the
PACA, we check the PID and if it's outside of the permitted range
we flush the TLB for that PID.
- When context switching, if the mm is "new" on that CPU (the
corresponding bit was set for the first time in the mm cpumask), we
check if any sibling thread is in KVM (has a non-NULL VCPU pointer
in the PACA). If that is the case, we also flush the PID for that
CPU (core).
This second part is needed to handle the case where a process is
migrated (or starts a new pthread) on a sibling thread of the CPU
coming out of KVM, as there's a window where stale translations can
exist before we detect it and flush them out.
A future optimization could be added by keeping track of whether the
PID has ever been used and avoid doing that for completely fresh PIDs.
We could similarily mark PIDs that have been the subject of a global
invalidation as "fresh". But for now this will do.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[mpe: Rework the asm to build with CONFIG_PPC_RADIX_MMU=n, drop
unneeded include of kvm_book3s_asm.h]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-23 22:26:06 -06:00
|
|
|
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
|
|
|
|
|
extern void radix_kvm_prefetch_workaround(struct mm_struct *mm)
|
|
|
|
|
{
|
2018-03-22 15:03:18 -06:00
|
|
|
unsigned long pid = mm->context.id;
|
powerpc/mm/radix: Workaround prefetch issue with KVM
There's a somewhat architectural issue with Radix MMU and KVM.
When coming out of a guest with AIL (Alternate Interrupt Location, ie,
MMU enabled), we start executing hypervisor code with the PID register
still containing whatever the guest has been using.
The problem is that the CPU can (and will) then start prefetching or
speculatively load from whatever host context has that same PID (if
any), thus bringing translations for that context into the TLB, which
Linux doesn't know about.
This can cause stale translations and subsequent crashes.
Fixing this in a way that is neither racy nor a huge performance
impact is difficult. We could just make the host invalidations always
use broadcast forms but that would hurt single threaded programs for
example.
We chose to fix it instead by partitioning the PID space between guest
and host. This is possible because today Linux only use 19 out of the
20 bits of PID space, so existing guests will work if we make the host
use the top half of the 20 bits space.
We additionally add support for a property to indicate to Linux the
size of the PID register which will be useful if we eventually have
processors with a larger PID space available.
There is still an issue with malicious guests purposefully setting the
PID register to a value in the hosts PID range. Hopefully future HW
can prevent that, but in the meantime, we handle it with a pair of
kludges:
- On the way out of a guest, before we clear the current VCPU in the
PACA, we check the PID and if it's outside of the permitted range
we flush the TLB for that PID.
- When context switching, if the mm is "new" on that CPU (the
corresponding bit was set for the first time in the mm cpumask), we
check if any sibling thread is in KVM (has a non-NULL VCPU pointer
in the PACA). If that is the case, we also flush the PID for that
CPU (core).
This second part is needed to handle the case where a process is
migrated (or starts a new pthread) on a sibling thread of the CPU
coming out of KVM, as there's a window where stale translations can
exist before we detect it and flush them out.
A future optimization could be added by keeping track of whether the
PID has ever been used and avoid doing that for completely fresh PIDs.
We could similarily mark PIDs that have been the subject of a global
invalidation as "fresh". But for now this will do.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[mpe: Rework the asm to build with CONFIG_PPC_RADIX_MMU=n, drop
unneeded include of kvm_book3s_asm.h]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-23 22:26:06 -06:00
|
|
|
|
|
|
|
|
if (unlikely(pid == MMU_NO_CONTEXT))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If this context hasn't run on that CPU before and KVM is
|
|
|
|
|
* around, there's a slim chance that the guest on another
|
|
|
|
|
* CPU just brought in obsolete translation into the TLB of
|
|
|
|
|
* this CPU due to a bad prefetch using the guest PID on
|
|
|
|
|
* the way into the hypervisor.
|
|
|
|
|
*
|
|
|
|
|
* We work around this here. If KVM is possible, we check if
|
|
|
|
|
* any sibling thread is in KVM. If it is, the window may exist
|
|
|
|
|
* and thus we flush that PID from the core.
|
|
|
|
|
*
|
|
|
|
|
* A potential future improvement would be to mark which PIDs
|
|
|
|
|
* have never been used on the system and avoid it if the PID
|
|
|
|
|
* is new and the process has no other cpumask bit set.
|
|
|
|
|
*/
|
|
|
|
|
if (cpu_has_feature(CPU_FTR_HVMODE) && radix_enabled()) {
|
|
|
|
|
int cpu = smp_processor_id();
|
|
|
|
|
int sib = cpu_first_thread_sibling(cpu);
|
|
|
|
|
bool flush = false;
|
|
|
|
|
|
|
|
|
|
for (; sib <= cpu_last_thread_sibling(cpu) && !flush; sib++) {
|
|
|
|
|
if (sib == cpu)
|
|
|
|
|
continue;
|
2018-06-12 03:38:08 -06:00
|
|
|
if (!cpu_possible(sib))
|
|
|
|
|
continue;
|
2018-02-13 08:08:12 -07:00
|
|
|
if (paca_ptrs[sib]->kvm_hstate.kvm_vcpu)
|
powerpc/mm/radix: Workaround prefetch issue with KVM
There's a somewhat architectural issue with Radix MMU and KVM.
When coming out of a guest with AIL (Alternate Interrupt Location, ie,
MMU enabled), we start executing hypervisor code with the PID register
still containing whatever the guest has been using.
The problem is that the CPU can (and will) then start prefetching or
speculatively load from whatever host context has that same PID (if
any), thus bringing translations for that context into the TLB, which
Linux doesn't know about.
This can cause stale translations and subsequent crashes.
Fixing this in a way that is neither racy nor a huge performance
impact is difficult. We could just make the host invalidations always
use broadcast forms but that would hurt single threaded programs for
example.
We chose to fix it instead by partitioning the PID space between guest
and host. This is possible because today Linux only use 19 out of the
20 bits of PID space, so existing guests will work if we make the host
use the top half of the 20 bits space.
We additionally add support for a property to indicate to Linux the
size of the PID register which will be useful if we eventually have
processors with a larger PID space available.
There is still an issue with malicious guests purposefully setting the
PID register to a value in the hosts PID range. Hopefully future HW
can prevent that, but in the meantime, we handle it with a pair of
kludges:
- On the way out of a guest, before we clear the current VCPU in the
PACA, we check the PID and if it's outside of the permitted range
we flush the TLB for that PID.
- When context switching, if the mm is "new" on that CPU (the
corresponding bit was set for the first time in the mm cpumask), we
check if any sibling thread is in KVM (has a non-NULL VCPU pointer
in the PACA). If that is the case, we also flush the PID for that
CPU (core).
This second part is needed to handle the case where a process is
migrated (or starts a new pthread) on a sibling thread of the CPU
coming out of KVM, as there's a window where stale translations can
exist before we detect it and flush them out.
A future optimization could be added by keeping track of whether the
PID has ever been used and avoid doing that for completely fresh PIDs.
We could similarily mark PIDs that have been the subject of a global
invalidation as "fresh". But for now this will do.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[mpe: Rework the asm to build with CONFIG_PPC_RADIX_MMU=n, drop
unneeded include of kvm_book3s_asm.h]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-07-23 22:26:06 -06:00
|
|
|
flush = true;
|
|
|
|
|
}
|
|
|
|
|
if (flush)
|
|
|
|
|
_tlbiel_pid(pid, RIC_FLUSH_ALL);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(radix_kvm_prefetch_workaround);
|
|
|
|
|
#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
|