Re: [RFC 00/16] Old GIC (gic-vgic) optimizations for GICV2

[Andre Przywara <andre.przywara@arm.com>]

On Thu, 29 Nov 2018 07:40:00 +0000
Andrii Anisov <Andrii_Anisov@epam.com> wrote:

> Hello,
> 
> Again, I sent this cover letter only to myself. So, here it is, hope
> it does not break the thread. Sorry for the mess.
> 
> 
> From: Andrii Anisov <andrii.anisov@gmail.com>
> Sent: Wednesday, November 28, 2018 11:31 PM
> Cc: Andrii Anisov
> Subject: [RFC 00/16] Old GIC (gic-vgic) optimizations for GICV2
>   
> 
> From: Andrii Anisov <andrii_anisov@epam.com>
> 
> This patch series is an attempt to reduce IRQ latency with the
> old GIC implementation (gic-vgic). These patches originally based
> on XEN 4.10 release. The motivation was to improve benchmark
> results of a system given to a customer for evaluation.

Have you tried the new VGIC? I am curious if you see a performance drop
compared to the old VGIC. It *should* be faster in the common case of
no (or maybe one) pending interrupts, because it doesn't bother to
touch LRs at all.

> This patch series is tailored for GICv2 on RCAR H3. Several
> of the most controversial patches (i.e. LRs shadowing) were
> not shared to the customer, and here are for comments and discussion.
> I hope several patches from here could be upstreamed. Some as is,
> others with modifications.
> 
> There are several simple ideas behind these changes:
>     - reduce an excessive code (condition checks)
>     - drop an excessive peripheral register accesses
>     - if not reduce, then move an excessive code out of spinlocks
>     - if not drop, then move an excessive register
>       accesses out of spinlocks

So some of the patches contain some good ideas, but as Julien said: we
would need some numbers to prove that they are worth it.

Cheers,
Andre.
 
> With porting existing patches, I've got another idea that accessing
> PER_CPU variables like `current` and `lr_mask` is not really cheap.
> So it should produce faster code keeping `lr_mask` solely in
> `struct vcpu` and pass `current` as a function parameter instead
> of calculation it each time in called functions.
> 
> Andrii Anisov (15):
>   hack: drop GIC v3 support
>   vgic: move pause_flags check out of vgic spinlock
>   vgic: move irq_to_pending out of lock
>   gic-vgic: Drop an excessive clear_lrs
>   gic: drop interrupts enabling on interrupts processing
>   gic-vgic:vgic: do not keep disabled IRQs in any of queues
>   gic: separate ppi processing
>   gic-vgic:vgic: avoid excessive conversions
>   gic:vgic:gic-vgic: introduce non-atomic bitops
>   irq: skip action avalability check for guest's IRQ
>   gic-v2: Write HCR only on change
>   gic-vgic: skip irqs locking
>   hack: arm/domain: simplify context restore from idle vcpu
>   hack: move gicv2 LRs reads and writes out of spinlocks
>   gic: vgic: align frequently accessed data by cache line size
> 
> Julien Grall (1):
>   xen/arm: Re-enable interrupt later in the trap path
> 
>  xen/arch/arm/arm64/entry.S           | 11 ++---
>  xen/arch/arm/configs/arm64_defconfig |  1 +
>  xen/arch/arm/domain.c                | 25 ++++++----
>  xen/arch/arm/gic-v2.c                | 63 ++++++++++++++++--------
>  xen/arch/arm/gic-v3-lpi.c            |  2 +
>  xen/arch/arm/gic-v3.c                |  2 +
>  xen/arch/arm/gic-vgic.c              | 84
> +++++++++++++++++++------------- xen/arch/arm/gic.c
> | 32 +++++++++++-- xen/arch/arm/irq.c                   | 46
> +++++++++++++++--- xen/arch/arm/traps.c                 |  6 +++
>  xen/arch/arm/vgic-v3-its.c           |  3 +-
>  xen/arch/arm/vgic.c                  | 93
> ++++++++++++++++++++++++++++++------
> xen/arch/arm/vgic/vgic.c             |  2 +
> xen/include/asm-arm/config.h         |  2 +-
> xen/include/asm-arm/gic.h            | 10 ++--
> xen/include/asm-arm/irq.h            |  3 ++
> xen/include/asm-arm/vgic.h           | 24 ++++++----
> xen/include/xen/sched.h              |  1 + 18 files changed, 299
> insertions(+), 111 deletions(-)
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel