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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Andrii,

Thank you for the numbers.

On 26/12/2018 11:20, Andrii Anisov wrote:
> From: Andrii Anisov <andrii_anisov@xxxxxxxx>
>
> 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.
> 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.
As long as it is tailored, I will not be able to properly review them. So a good 
start is to try to get the series upstream is removing all your hack and 
avoiding tailoring this to the RCAR H3.
> 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
>
> This is a v2 of the original RFC series [1]. From that series, patches
> [2] and [3] have already reached mainline. Here few patches are reworked
> with addressing some comments or separating them into more clear pieces,
> more patches are taken from the RFC v1 as is.
It is a quite frustrating to see 16 more patches in my inbox with most of my 
comments not addressed or even answered. The number could just have been posted 
on the RFCv1 avoiding to spam my mailbox.
> The main intention of this version of RFC series is to reveal
> patch-by-patch IRQ latency impact.
> The measurement is performed with TBM [4], so the use-case is trivial -
> passing a single IRQ twice in a second. Thus no lock contentions nor
> even passing more than one interrupt to a guest at the time use-cases
> are hit.
>
> The series is based on the current xenbits/staging, commit 7f28661f6a7.
> XEN is build with no DEBUG and no GICv3 support for the staging HEAD and
> each commit. Four runtime configurations are evaluated for each commit:
>      - sched=credit2 vwfi=trap
>      - sched=credit2 vwfi=native
>      - sched=credit vwfi=trap
>      - sched=credit vwfi=native
>
> Each commit is incrementally cherry-picked for the latency evaluation in
> an order they appear in the table. The table also can be found shared
> as a Google spreadsheet here [5].
Can you format the Google spreadsheet in a usable way? By that I mean having 
only one number per column so we can add a bit more formula in it.
I will comment on the number once they are in better shape.

Cheers,

--
Julien Grall

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