[<prev] [next>] [day] [month] [year] [list]
Message-ID: <86d05f68-e644-8b05-3154-4658813e986e@arm.com>
Date: Tue, 24 Dec 2019 14:03:35 +0000
From: Valentin Schneider <valentin.schneider@....com>
To: linux-kernel <linux-kernel@...r.kernel.org>,
LAK <linux-arm-kernel@...ts.infradead.org>,
tee-dev@...ts.linaro.org, netdev@...r.kernel.org
Cc: vikas.gupta@...adcom.com, jakub.kicinski@...ronome.com,
sheetal.tigadoli@...adcom.com, davem@...emloft.net,
Vincent Guittot <vincent.guittot@...aro.org>
Subject: 5.5-rc1 regression with BNXT firmware driver
Hi,
I've been hunting down some hackbench regression between 5.4-rc8 and 5.5-rc1
on my Juno r0, one of the offenders seems to be:
246880958ac9 ("firmware: broadcom: add OP-TEE based BNXT f/w manager")
This is tested on a kernel built with defconfig (TEE_BNXT_FW gets selected)
and with:
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
./perf stat --null --sync --repeat 200 ./hackbench
The regression is easily reproducible on my end, this is 3 runs of the above
comparing the patch and its parent:
-PATCH:
0.71062 +- 0.00150 seconds time elapsed ( +- 0.21% )
0.71121 +- 0.00181 seconds time elapsed ( +- 0.25% )
0.71277 +- 0.00181 seconds time elapsed ( +- 0.25% )
+PATCH:
0.72556 +- 0.00174 seconds time elapsed ( +- 0.24% )
0.72695 +- 0.00192 seconds time elapsed ( +- 0.26% )
0.72559 +- 0.00178 seconds time elapsed ( +- 0.25% )
AIUI Vincent found something different while hunting down a similar
regression:
df323337e507 ("apparmor: Use a memory pool instead per-CPU caches")
but it seems this one is another cause. Seeing as this involves security
stuff the overhead may be acceptable, nevertheless now that I have some
reproducer I figured I'd send this out.
Cheers,
Valentin
Powered by blists - more mailing lists