search for: flush_tlb_oth

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....

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....

...> @@ -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-...

...> @@ -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-...

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....

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....

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....

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....

...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...

...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...

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...

...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...

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...

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...

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

...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...

...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...

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

.../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....

...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...