search for: flush_tlb_oth

Displaying 20 results from an estimated 84 matches for "flush_tlb_oth".

Did you mean: flush_tlb_one
2019 May 25
3
[RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently
To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. The current flush_tlb_others() interface is kept, since paravirtual interfaces need to be adapted first before it can be removed. This is left for future work. In such PV environments, TLB flushes are not performed, at this time, concurrently. Add a static key to tell whether this new interface is supported. Cc: "K....
2019 May 25
3
[RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently
To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. The current flush_tlb_others() interface is kept, since paravirtual interfaces need to be adapted first before it can be removed. This is left for future work. In such PV environments, TLB flushes are not performed, at this time, concurrently. Add a static key to tell whether this new interface is supported. Cc: "K....
2019 May 27
3
[RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently
...> @@ -211,6 +211,12 @@ struct pv_mmu_ops { > > void (*flush_tlb_user)(void); > > void (*flush_tlb_kernel)(void); > > void (*flush_tlb_one_user)(unsigned long addr); > > + /* > > + * flush_tlb_multi() is the preferred interface. When it is used, > > + * flush_tlb_others() should return false. > > This comment does not make sense. flush_tlb_others() return type is > void. I suspect that is an artifact from before the static_key; an attempt to make the pv interface less awkward. Something like the below would work for KVM I suspect, the others (Hyper-...
2019 May 27
3
[RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently
...> @@ -211,6 +211,12 @@ struct pv_mmu_ops { > > void (*flush_tlb_user)(void); > > void (*flush_tlb_kernel)(void); > > void (*flush_tlb_one_user)(unsigned long addr); > > + /* > > + * flush_tlb_multi() is the preferred interface. When it is used, > > + * flush_tlb_others() should return false. > > This comment does not make sense. flush_tlb_others() return type is > void. I suspect that is an artifact from before the static_key; an attempt to make the pv interface less awkward. Something like the below would work for KVM I suspect, the others (Hyper-...
2019 Jun 13
4
[PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. The current flush_tlb_others() interface is kept, since paravirtual interfaces need to be adapted first before it can be removed. This is left for future work. In such PV environments, TLB flushes are not performed, at this time, concurrently. Add a static key to tell whether this new interface is supported. Cc: "K....
2019 Jun 13
4
[PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. The current flush_tlb_others() interface is kept, since paravirtual interfaces need to be adapted first before it can be removed. This is left for future work. In such PV environments, TLB flushes are not performed, at this time, concurrently. Add a static key to tell whether this new interface is supported. Cc: "K....
2019 May 31
2
[RFC PATCH v2 04/12] x86/mm/tlb: Flush remote and local TLBs concurrently
To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. The current flush_tlb_others() interface is kept, since paravirtual interfaces need to be adapted first before it can be removed. This is left for future work. In such PV environments, TLB flushes are not performed, at this time, concurrently. Add a static key to tell whether this new interface is supported. Cc: "K....
2019 May 31
2
[RFC PATCH v2 04/12] x86/mm/tlb: Flush remote and local TLBs concurrently
To improve TLB shootdown performance, flush the remote and local TLBs concurrently. Introduce flush_tlb_multi() that does so. The current flush_tlb_others() interface is kept, since paravirtual interfaces need to be adapted first before it can be removed. This is left for future work. In such PV environments, TLB flushes are not performed, at this time, concurrently. Add a static key to tell whether this new interface is supported. Cc: "K....
2019 Jul 19
0
[PATCH v3 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
...41 deletions(-) diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c index e65d7fe6489f..8740d8b21db3 100644 --- a/arch/x86/hyperv/mmu.c +++ b/arch/x86/hyperv/mmu.c @@ -50,8 +50,8 @@ static inline int fill_gva_list(u64 gva_list[], int offset, return gva_n - offset; } -static void hyperv_flush_tlb_others(const struct cpumask *cpus, - const struct flush_tlb_info *info) +static void hyperv_flush_tlb_multi(const struct cpumask *cpus, + const struct flush_tlb_info *info) { int cpu, vcpu, gva_n, max_gvas; struct hv_tlb_flush **flush_pcpu; @@ -59,7 +59,7 @@ static void hyperv_flush_t...
2019 Jul 02
0
[PATCH v2 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
...43 deletions(-) diff --git a/arch/x86/hyperv/mmu.c b/arch/x86/hyperv/mmu.c index e65d7fe6489f..1177f863e4cd 100644 --- a/arch/x86/hyperv/mmu.c +++ b/arch/x86/hyperv/mmu.c @@ -50,8 +50,8 @@ static inline int fill_gva_list(u64 gva_list[], int offset, return gva_n - offset; } -static void hyperv_flush_tlb_others(const struct cpumask *cpus, - const struct flush_tlb_info *info) +static void hyperv_flush_tlb_multi(const struct cpumask *cpus, + const struct flush_tlb_info *info) { int cpu, vcpu, gva_n, max_gvas; struct hv_tlb_flush **flush_pcpu; @@ -59,7 +59,7 @@ static void hyperv_flush_t...
2019 May 25
0
[RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently
On 25/05/2019 10:22, Nadav Amit wrote: > To improve TLB shootdown performance, flush the remote and local TLBs > concurrently. Introduce flush_tlb_multi() that does so. The current > flush_tlb_others() interface is kept, since paravirtual interfaces need > to be adapted first before it can be removed. This is left for future > work. In such PV environments, TLB flushes are not performed, at this > time, concurrently. > > Add a static key to tell whether this new interface is...
2019 Jun 26
1
[PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
...Lutomirski <luto at kernel.org> wrote: > > On Wed, Jun 12, 2019 at 11:49 PM Nadav Amit <namit at vmware.com> wrote: >> To improve TLB shootdown performance, flush the remote and local TLBs >> concurrently. Introduce flush_tlb_multi() that does so. The current >> flush_tlb_others() interface is kept, since paravirtual interfaces need >> to be adapted first before it can be removed. This is left for future >> work. In such PV environments, TLB flushes are not performed, at this >> time, concurrently. > > Would it be straightforward to have a defau...
2019 Jun 25
0
[PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
On 6/12/19 11:48 PM, Nadav Amit wrote: > To improve TLB shootdown performance, flush the remote and local TLBs > concurrently. Introduce flush_tlb_multi() that does so. The current > flush_tlb_others() interface is kept, since paravirtual interfaces need > to be adapted first before it can be removed. This is left for future > work. In such PV environments, TLB flushes are not performed, at this > time, concurrently. > > Add a static key to tell whether this new interface is...
2019 May 31
0
[RFC PATCH v2 04/12] x86/mm/tlb: Flush remote and local TLBs concurrently
On 31/05/2019 08:36, Nadav Amit wrote: > To improve TLB shootdown performance, flush the remote and local TLBs > concurrently. Introduce flush_tlb_multi() that does so. The current > flush_tlb_others() interface is kept, since paravirtual interfaces need > to be adapted first before it can be removed. This is left for future > work. In such PV environments, TLB flushes are not performed, at this > time, concurrently. > > Add a static key to tell whether this new interface is...
2019 Jul 02
2
[PATCH v2 0/9] x86: Concurrent TLB flushes
Currently, local and remote TLB flushes are not performed concurrently, which introduces unnecessary overhead - each INVLPG can take 100s of cycles. This patch-set allows TLB flushes to be run concurrently: first request the remote CPUs to initiate the flush, then run it locally, and finally wait for the remote CPUs to finish their work. In addition, there are various small optimizations to avoid
2019 Jun 26
2
[PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
...gt; On Jun 25, 2019, at 2:29 PM, Dave Hansen <dave.hansen at intel.com> wrote: > > On 6/12/19 11:48 PM, Nadav Amit wrote: >> To improve TLB shootdown performance, flush the remote and local TLBs >> concurrently. Introduce flush_tlb_multi() that does so. The current >> flush_tlb_others() interface is kept, since paravirtual interfaces need >> to be adapted first before it can be removed. This is left for future >> work. In such PV environments, TLB flushes are not performed, at this >> time, concurrently. >> >> Add a static key to tell whether th...
2019 Jun 26
2
[PATCH 4/9] x86/mm/tlb: Flush remote and local TLBs concurrently
...gt; On Jun 25, 2019, at 2:29 PM, Dave Hansen <dave.hansen at intel.com> wrote: > > On 6/12/19 11:48 PM, Nadav Amit wrote: >> To improve TLB shootdown performance, flush the remote and local TLBs >> concurrently. Introduce flush_tlb_multi() that does so. The current >> flush_tlb_others() interface is kept, since paravirtual interfaces need >> to be adapted first before it can be removed. This is left for future >> work. In such PV environments, TLB flushes are not performed, at this >> time, concurrently. >> >> Add a static key to tell whether th...
2017 May 15
2
Support of lguest?
Lguest and Xen pv-guests are the only users of pv_mmu_ops (with the one exception of the .exit_mmap member, which is being used by Xen HVM-guests, too). As it is possible now to build a kernel without Xen pv-guest support while keeping PVH and PVHVM support, I thought about putting most pv_mmu_ops functions in #ifdef CONFIG_XEN_HAS_PVMMU sections. If there wouldn't be lguest... So my
2018 Aug 10
0
[Xen-devel] [PATCH 04/10] x86/paravirt: use a single ops structure
.../hyperv/mmu.c >> +++ b/arch/x86/hyperv/mmu.c >> @@ -228,9 +228,9 @@ void hyperv_setup_mmu_ops(void) >> >> if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED)) { >> pr_info("Using hypercall for remote TLB flush\n"); >> - pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others; >> + pv_ops.pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others; > > Taking just this as example, why not > > pv_ops.mmu.flush_tlb_others = hyperv_flush_tlb_others; > > ? Both pv_ and _ops are redundant on the field names. Good idea....
2019 May 27
0
[RFC PATCH 5/6] x86/mm/tlb: Flush remote and local TLBs concurrently
...1,12 @@ struct pv_mmu_ops { >>> void (*flush_tlb_user)(void); >>> void (*flush_tlb_kernel)(void); >>> void (*flush_tlb_one_user)(unsigned long addr); >>> + /* >>> + * flush_tlb_multi() is the preferred interface. When it is used, >>> + * flush_tlb_others() should return false. >> >> This comment does not make sense. flush_tlb_others() return type is >> void. > > I suspect that is an artifact from before the static_key; an attempt to > make the pv interface less awkward. > > Something like the below would work f...