| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 27 Oct 2020 11:12:15 +0100
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Marc Zyngier <maz@...nel.org>
Cc: LAK <linux-arm-kernel@...ts.infradead.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Will Deacon <will@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Russell King <linux@....linux.org.uk>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Sumit Garg <sumit.garg@...aro.org>,
Valentin Schneider <Valentin.Schneider@....com>,
Florian Fainelli <f.fainelli@...il.com>,
Gregory Clement <gregory.clement@...tlin.com>,
Andrew Lunn <andrew@...n.ch>,
Saravana Kannan <saravanak@...gle.com>,
Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH v3 03/16] arm64: Allow IPIs to be handled as normal interrupts
HI Marc,
On Mon, 19 Oct 2020 at 17:43, Vincent Guittot
<vincent.guittot@...aro.org> wrote:
>
> On Mon, 19 Oct 2020 at 15:04, Marc Zyngier <maz@...nel.org> wrote:
> >
...
> > >>
> > >> 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().
> >
> > >
> > > 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
>
> hmm... Difficult to say because tracing the bench decreases a lot the
> result. I have pasted the perf reports.
>
> With this patch :
>
> # Samples: 634 of event 'cpu-clock'
> # Event count (approx.): 158500000
> #
> # Overhead Command Shared Object Symbol
> # ........ .......... .................. ..................................
> #
> 31.86% sched-pipe [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
> 8.68% sched-pipe [kernel.kallsyms] [k] _raw_spin_unlock_irq
> 6.31% sched-pipe [kernel.kallsyms] [k] __schedule
> 5.21% sched-pipe [kernel.kallsyms] [k] schedule
> 4.73% sched-pipe [kernel.kallsyms] [k] pipe_read
> 3.31% sched-pipe [kernel.kallsyms] [k] el0_svc_common.constprop.3
> 2.84% sched-pipe [kernel.kallsyms] [k] ww_mutex_lock_interruptible
> 2.52% sched-pipe [kernel.kallsyms] [k] init_wait_entry
> 2.37% sched-pipe [kernel.kallsyms] [k] mutex_unlock
> 2.21% sched-pipe [kernel.kallsyms] [k] new_sync_read
> 1.89% sched-pipe [kernel.kallsyms] [k] new_sync_write
> 1.74% sched-pipe [kernel.kallsyms] [k] security_file_permission
> 1.74% sched-pipe [kernel.kallsyms] [k] vfs_read
> 1.58% sched-pipe [kernel.kallsyms] [k] __my_cpu_offset
> 1.26% sched-pipe libpthread-2.24.so [.] 0x0000000000010a2c
> 1.10% sched-pipe [kernel.kallsyms] [k] mutex_lock
> 1.10% sched-pipe [kernel.kallsyms] [k] vfs_write
>
> After reverting this patch which gives a result similar to v5.9:
>
> # Samples: 659 of event 'cpu-clock'
> # Event count (approx.): 164750000
> #
> # Overhead Command Shared Object Symbol
> # ........ .......... .................. ...............................
> #
> 29.29% sched-pipe [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
> 21.40% sched-pipe [kernel.kallsyms] [k] _raw_spin_unlock_irq
> 4.86% sched-pipe [kernel.kallsyms] [k] pipe_read
> 4.55% sched-pipe [kernel.kallsyms] [k] ww_mutex_lock_interruptible
> 2.88% sched-pipe [kernel.kallsyms] [k] __schedule
> 2.88% sched-pipe [kernel.kallsyms] [k] _raw_spin_lock_irqsave
> 2.88% sched-pipe [kernel.kallsyms] [k] schedule
> 2.12% sched-pipe [kernel.kallsyms] [k] new_sync_read
> 1.82% sched-pipe [kernel.kallsyms] [k] mutex_lock
> 1.67% sched-pipe [kernel.kallsyms] [k] el0_svc_common.constprop.3
> 1.67% sched-pipe [kernel.kallsyms] [k] pipe_write
> 1.21% sched-pipe [kernel.kallsyms] [k] rw_verify_area
> 1.21% sched-pipe [kernel.kallsyms] [k] security_file_permission
> 1.06% sched-pipe [kernel.kallsyms] [k] fsnotify
>
> I have only put symbol with overhead above 1%
>
> so _raw_spin_unlock_irq, schedule and __schedule seem the most
> impacted but i can't get any conclusion
>
> I can sent you perf.data files if you want
>
>
> >
> > Thanks,
> >
> > M.
> > --
> > Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists