PROVE_LOCKING enables LOCKDEP, which causes big overhead on cache and
bus transactions.
On some ARM big.LITTLE architecutres (Exynos 5433) the overhead is really big.
The overhead can be measures using hackbench which will speed up
by x3 times (11sec -> 3.4sec).
When you check transaction on cache or buses, the results are way higher
than normal for the same hackbench test:
L1d cache invalidations: 26mln vs 4mln
L2u cache invalidations: 42mln vs 12mln
bus cyc/access: 30cyc/access vs. 20cyc/access
context switch is x3 times cheaper
Enable this option only when you have some locking issue to investigate.
Signed-off-by: Lukasz Luba <[email protected]>
---
arch/arm/configs/omap2plus_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 6491419..1bbfd76 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -536,7 +536,6 @@ CONFIG_DEBUG_INFO_SPLIT=y
CONFIG_DEBUG_INFO_DWARF4=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_SCHEDSTATS=y
-CONFIG_PROVE_LOCKING=y
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_SECURITY=y
CONFIG_CRYPTO_MICHAEL_MIC=y
--
2.7.4
Hi,
* Lukasz Luba <[email protected]> [181009 08:36]:
> PROVE_LOCKING enables LOCKDEP, which causes big overhead on cache and
> bus transactions.
>
> On some ARM big.LITTLE architecutres (Exynos 5433) the overhead is really big.
> The overhead can be measures using hackbench which will speed up
> by x3 times (11sec -> 3.4sec).
> When you check transaction on cache or buses, the results are way higher
> than normal for the same hackbench test:
> L1d cache invalidations: 26mln vs 4mln
> L2u cache invalidations: 42mln vs 12mln
> bus cyc/access: 30cyc/access vs. 20cyc/access
> context switch is x3 times cheaper
>
> Enable this option only when you have some locking issue to investigate.
I'm all for this, but this disables also other less intrusive
debug options. It used to be that we'd get locking issues merged
into drivers and I think that's how it originally got enabled.
So we should take a look which ones we can or want to keep.
Or just disable CONFIG_DEBUG completely.
For distros, that's multi_v7_defconfig nowadays for most part
so I think most people using omap2plus_defconfig are developers
working on various devices.
Regards,
Tony
> Signed-off-by: Lukasz Luba <[email protected]>
> ---
> arch/arm/configs/omap2plus_defconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
> index 6491419..1bbfd76 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -536,7 +536,6 @@ CONFIG_DEBUG_INFO_SPLIT=y
> CONFIG_DEBUG_INFO_DWARF4=y
> CONFIG_MAGIC_SYSRQ=y
> CONFIG_SCHEDSTATS=y
> -CONFIG_PROVE_LOCKING=y
> # CONFIG_DEBUG_BUGVERBOSE is not set
> CONFIG_SECURITY=y
> CONFIG_CRYPTO_MICHAEL_MIC=y
> --
> 2.7.4
>
Hi Tony,
On 11/8/18 5:59 PM, Tony Lindgren wrote:
> Hi,
>
> * Lukasz Luba <[email protected]> [181009 08:36]:
>> PROVE_LOCKING enables LOCKDEP, which causes big overhead on cache and
>> bus transactions.
>>
>> On some ARM big.LITTLE architecutres (Exynos 5433) the overhead is really big.
>> The overhead can be measures using hackbench which will speed up
>> by x3 times (11sec -> 3.4sec).
>> When you check transaction on cache or buses, the results are way higher
>> than normal for the same hackbench test:
>> L1d cache invalidations: 26mln vs 4mln
>> L2u cache invalidations: 42mln vs 12mln
>> bus cyc/access: 30cyc/access vs. 20cyc/access
>> context switch is x3 times cheaper
>>
>> Enable this option only when you have some locking issue to investigate.
>
> I'm all for this, but this disables also other less intrusive
> debug options. It used to be that we'd get locking issues merged
> into drivers and I think that's how it originally got enabled.
That's common reason for a few defconfigs in mainline.
>
> So we should take a look which ones we can or want to keep.
> Or just disable CONFIG_DEBUG completely.
Ideally, the CI should try a few 'types' of configs,
generated based on the 'defconfig'. Some 'smart' script might
cut the debug options for an image for performance regression tests.
>
> For distros, that's multi_v7_defconfig nowadays for most part
> so I think most people using omap2plus_defconfig are developers
> working on various devices.
>
> Regards,
>
> Tony
Regards,
Lukasz
* Lukasz Luba <[email protected]> [181113 10:22]:
> Hi Tony,
>
> On 11/8/18 5:59 PM, Tony Lindgren wrote:
> > Hi,
> >
> > * Lukasz Luba <[email protected]> [181009 08:36]:
> >> PROVE_LOCKING enables LOCKDEP, which causes big overhead on cache and
> >> bus transactions.
> >>
> >> On some ARM big.LITTLE architecutres (Exynos 5433) the overhead is really big.
> >> The overhead can be measures using hackbench which will speed up
> >> by x3 times (11sec -> 3.4sec).
> >> When you check transaction on cache or buses, the results are way higher
> >> than normal for the same hackbench test:
> >> L1d cache invalidations: 26mln vs 4mln
> >> L2u cache invalidations: 42mln vs 12mln
> >> bus cyc/access: 30cyc/access vs. 20cyc/access
> >> context switch is x3 times cheaper
> >>
> >> Enable this option only when you have some locking issue to investigate.
> >
> > I'm all for this, but this disables also other less intrusive
> > debug options. It used to be that we'd get locking issues merged
> > into drivers and I think that's how it originally got enabled.
> That's common reason for a few defconfigs in mainline.
Actually looks like this does not change the DEBUG
related options.. I must have done something wrong
earlier, sorry. So applying into omap-for-v5.1/defconfig.
> > So we should take a look which ones we can or want to keep.
> > Or just disable CONFIG_DEBUG completely.
> Ideally, the CI should try a few 'types' of configs,
> generated based on the 'defconfig'. Some 'smart' script might
> cut the debug options for an image for performance regression tests.
> >
> > For distros, that's multi_v7_defconfig nowadays for most part
> > so I think most people using omap2plus_defconfig are developers
> > working on various devices.
Yes I think that's the case.
Regards,
Tony