|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 7/7] x86/tlb: use Xen L0 assisted TLB flush when available
On 19.02.2020 18:43, Roger Pau Monne wrote:
> Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
> This greatly increases the performance of TLB flushes when running
> with a high amount of vCPUs as a Xen guest, and is specially important
> when running in shim mode.
>
> The following figures are from a PV guest running `make -j32 xen` in
> shim mode with 32 vCPUs and HAP.
>
> Using x2APIC and ALLBUT shorthand:
> real 4m35.973s
> user 4m35.110s
> sys 36m24.117s
>
> Using L0 assisted flush:
> real 1m2.596s
> user 4m34.818s
> sys 5m16.374s
>
> The implementation adds a new hook to hypervisor_ops so other
> enlightenments can also implement such assisted flush just by filling
> the hook. Note that the Xen implementation completely ignores the
> dirty CPU mask and the linear address passed in, and always performs a
> global TLB flush on all vCPUs.
This isn't because of an implementation choice of yours, but because
of how HVMOP_flush_tlbs works. I think the statement should somehow
express this. I also think it wants clarifying that using the
hypercall is indeed faster even in the case of single-page, single-
CPU flush (which I suspect may not be the case especially as vCPU
count grows). The stats above prove a positive overall effect, but
they don't say whether the effect could be even bigger by being at
least a little selective.
> @@ -73,6 +74,15 @@ void __init hypervisor_e820_fixup(struct e820map *e820)
> ops.e820_fixup(e820);
> }
>
> +int hypervisor_flush_tlb(const cpumask_t *mask, const void *va,
> + unsigned int order)
> +{
> + if ( ops.flush_tlb )
> + return alternative_call(ops.flush_tlb, mask, va, order);
> +
> + return -ENOSYS;
> +}
Please no new -ENOSYS anywhere (except in new ports' top level
hypercall handlers).
> @@ -256,6 +257,16 @@ void flush_area_mask(const cpumask_t *mask, const void
> *va, unsigned int flags)
> if ( (flags & ~FLUSH_ORDER_MASK) &&
> !cpumask_subset(mask, cpumask_of(cpu)) )
> {
> + if ( cpu_has_hypervisor &&
> + !(flags & ~(FLUSH_TLB | FLUSH_TLB_GLOBAL | FLUSH_VA_VALID |
> + FLUSH_ORDER_MASK)) &&
> + !hypervisor_flush_tlb(mask, va, (flags - 1) & FLUSH_ORDER_MASK)
> )
> + {
> + if ( tlb_clk_enabled )
> + tlb_clk_enabled = false;
Why does this need doing here? Couldn't Xen guest setup code
clear the flag?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |