On Tue, 27 Oct 2020 at 11:50, Vincent Guittot
[off-list ref] wrote:

On Tue, 27 Oct 2020 at 11:37, Marc Zyngier [off-list ref] wrote:

quoted

On 2020-10-27 10:12, Vincent Guittot wrote:

quoted

HI Marc,

On Mon, 19 Oct 2020 at 17:43, Vincent Guittot
[off-list ref] wrote:

quoted

On Mon, 19 Oct 2020 at 15:04, Marc Zyngier [off-list ref] wrote:

quoted

...

quoted

quoted

quoted

quoted

One of the major difference is that we end up, in some cases
(such as when performing IRQ time accounting on the scheduler
IPI), end up with nested irq_enter()/irq_exit() pairs.
Other than the (relatively small) overhead, there should be
no consequences to it (these pairs are designed to nest
correctly, and the accounting shouldn't be off).

While rebasing on mainline, I have faced a performance regression for
the benchmark:
perf bench sched pipe
on my arm64 dual quad core (hikey) and my 2 nodes x 112 CPUS (thx2)

The regression comes from:
commit: d3afc7f12987 ("arm64: Allow IPIs to be handled as normal
interrupts")

That's interesting, as this patch doesn't really change anything (most
of the potential overhead comes in later). The only potential overhead
I can see is that the scheduler_ipi() call is now wrapped around
irq_enter()/irq_exit().

quoted

          v5.9              + this patch
hikey :   48818(+/- 0.31)   37503(+/- 0.15%)  -23.2%
thx2  :  132410(+/- 1.72)  122646(+/- 1.92%)   -7.4%

By + this patch,  I mean merging branch from this patch. Whereas
merging the previous:
commit: 83cfac95c018 ("genirq: Allow interrupts to be excluded from
/proc/interrupts")
 It doesn't show any regression

Since you are running perf, can you spot where the overhead occurs?

Any idea about the root cause of the regression ?
I have faced it on more arm64 platforms in the meantime

two possible causes:

(1) irq_enter/exit on the rescheduling IPI means we reschedule much more
often
(2) irq_domain lookups add some overhead.

For (1), I have this series[1] which is ugly as sin and needs much more
testing.

Ok, I'm going to test this series to see if it fixes the perf regression

You have spotted the root cause of the regression. We are back to ~1%
performance diff on the hikey

quoted

For (2), I have some ideas which need more work (let the irq domain
resolve to
an irq_desc instead of an interrupt number, avoiding another radix-tree
lookup).

         M.

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/ipi-fixes
--
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel