This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

GICv2 vs GICv3 differences

Hi all,

One of the improvements introduced by GICv3 was the ICC_* sysregs CPU interface which is no longer memory mapped. In terms of scalability this interface is clear, but what about performance?

(i) Is sysreg instruction MSR/MRS faster than accessing device memory?



Now lets assume that we have GICv2 with memory-mapped interface:

(ii) Are accesses to GICv2 CPU interface typically faster than GICv2 Distributer, both having same attributes for device memory mapping.

Thanks in advance.

Cheers.

  • Ahh, GIC - my favourite topic :-) 

    Is sysreg instruction MSR/MRS faster than accessing device memory?

    Likely, yes.  The architecture defines behaviours, not a specific design, and performance will depend on the exact implementation.  In this case the system register approach has a couple of advantages.

    With GICv3, the GIC forwards a packet to the core describing the interrupt (ID, Group, Priority).  When, within the interrupt handler, software reads ICC_IARx_EL1 to acknowledge the interrupt, the core already has all the information it needs to return the interrupt ID (INTID).

    With GICv2, the equivalent step requires a read of an MMIO register.  That read has to get from the core to the GIC, and then back, before software knows the INTID.  How long will that take?  It depends on the specific system design and can also depend on how much contention there is on the memory system at the time.

    Another advantage is to software - in the interrupt handling path you don't need to know the address of the interrupt controller to perform the acknowledge.

    Are accesses to GICv2 CPU interface typically faster than GICv2 Distributer, both having same attributes for device memory mapping.

    I wouldn't expect them to be that different, although again it'd depend on the exact implementation.

    However, there is a practical difference.  Software needs to use the GICC registers every time it handles an interrupt.  Software only needs to access GICD registers to re-configure an interrupt.  Re-configuring an interrupt is usually much rarer than handling an interrupt, and is also less likely to be latency-sensitive.  So it probably matters much less if a GICD access is comparatively slow.