[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.