[PATCH] lib/Kconfig.debug: add a comment to PROVE_LOCKING impact

[PATCH] lib/Kconfig.debug: add a comment to PROVE_LOCKING impact

[Lukasz Luba]

This patch add some comment related to performance impact,
which can be really big (x3 times slower context switch).

Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
---
 lib/Kconfig.debug | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 4966c4f..9e67a2a3 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1088,6 +1088,9 @@ config PROVE_LOCKING
 	 the proof of observed correctness is also maintained for an
 	 arbitrary combination of these separate locking variants.
 
+	 This feature enables LOCKDEP which can harm system performance
+	 even x3 times.
+
 	 For more details, see Documentation/locking/lockdep-design.txt.
 
 config LOCK_STAT
@@ -1112,6 +1115,10 @@ config LOCK_STAT
 	 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
 	 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
 
+	 This feature enables LOCKDEP which can harm system performance
+	 even x3 times.
+	 For more details, see Documentation/locking/lockdep-design.txt.
+
 config DEBUG_RT_MUTEXES
 	bool "RT Mutex debugging, deadlock detection"
 	depends on DEBUG_KERNEL && RT_MUTEXES
@@ -1175,6 +1182,10 @@ config DEBUG_LOCK_ALLOC
 	 spin_lock_init()/mutex_init()/etc., or whether there is any lock
 	 held during task exit.
 
+	 This feature enables LOCKDEP which can harm system performance
+	 even x3 times.
+	 For more details, see Documentation/locking/lockdep-design.txt.
+
 config LOCKDEP
 	bool
 	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
-- 
2.7.4

Re: [PATCH] lib/Kconfig.debug: add a comment to PROVE_LOCKING impact

[Nikolay Borisov]

On  9.10.2018 18:39, Lukasz Luba wrote:
> This patch add some comment related to performance impact,
> which can be really big (x3 times slower context switch).
> 
> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>

I don't think this brings any value. lockdep is a debugging aid aimed at
developers. A developer should be aware that it has a performance impact
and the classification x3 doesn't really bring anything.
> ---
>  lib/Kconfig.debug | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 4966c4f..9e67a2a3 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1088,6 +1088,9 @@ config PROVE_LOCKING
>  	 the proof of observed correctness is also maintained for an
>  	 arbitrary combination of these separate locking variants.
>  
> +	 This feature enables LOCKDEP which can harm system performance
> +	 even x3 times.
> +
>  	 For more details, see Documentation/locking/lockdep-design.txt.
>  
>  config LOCK_STAT
> @@ -1112,6 +1115,10 @@ config LOCK_STAT
>  	 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
>  	 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
>  
> +	 This feature enables LOCKDEP which can harm system performance
> +	 even x3 times.
> +	 For more details, see Documentation/locking/lockdep-design.txt.
> +
>  config DEBUG_RT_MUTEXES
>  	bool "RT Mutex debugging, deadlock detection"
>  	depends on DEBUG_KERNEL && RT_MUTEXES
> @@ -1175,6 +1182,10 @@ config DEBUG_LOCK_ALLOC
>  	 spin_lock_init()/mutex_init()/etc., or whether there is any lock
>  	 held during task exit.
>  
> +	 This feature enables LOCKDEP which can harm system performance
> +	 even x3 times.
> +	 For more details, see Documentation/locking/lockdep-design.txt.
> +
>  config LOCKDEP
>  	bool
>  	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
> 

Re: [PATCH] lib/Kconfig.debug: add a comment to PROVE_LOCKING impact

[Waiman Long]

On 10/09/2018 11:39 AM, Lukasz Luba wrote:
> This patch add some comment related to performance impact,
> which can be really big (x3 times slower context switch).
>
> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
> ---
>  lib/Kconfig.debug | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 4966c4f..9e67a2a3 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1088,6 +1088,9 @@ config PROVE_LOCKING
>  	 the proof of observed correctness is also maintained for an
>  	 arbitrary combination of these separate locking variants.
>  
> +	 This feature enables LOCKDEP which can harm system performance
> +	 even x3 times.
> +
>  	 For more details, see Documentation/locking/lockdep-design.txt.
>  
>  config LOCK_STAT
> @@ -1112,6 +1115,10 @@ config LOCK_STAT
>  	 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
>  	 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
>  
> +	 This feature enables LOCKDEP which can harm system performance
> +	 even x3 times.
> +	 For more details, see Documentation/locking/lockdep-design.txt.
> +
>  config DEBUG_RT_MUTEXES
>  	bool "RT Mutex debugging, deadlock detection"
>  	depends on DEBUG_KERNEL && RT_MUTEXES
> @@ -1175,6 +1182,10 @@ config DEBUG_LOCK_ALLOC
>  	 spin_lock_init()/mutex_init()/etc., or whether there is any lock
>  	 held during task exit.
>  
> +	 This feature enables LOCKDEP which can harm system performance
> +	 even x3 times.
> +	 For more details, see Documentation/locking/lockdep-design.txt.
> +
>  config LOCKDEP
>  	bool
>  	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT

I don't mind seeing warning message about the performance impact of
enabling lockdep. However, the actual slowdown depends on many factors
including the type of systems, workloads and so on. I am a bit hesitant
to quote an actual figure like x3 in the help text as it may not be
correct in many cases.

BTW, my recent lockdep patch (https://lkml.org/lkml/2018/10/2/1410)
should be able to reduce the performance impact of enabling lockdep.
Could you try to see if that help in your case?

Cheers,
Longman

Re: [PATCH] lib/Kconfig.debug: add a comment to PROVE_LOCKING impact

[Lukasz Luba]

Hi Longman,

Thanks for the patches. I have applied them and run on ARM.
In context switch test, there is ~2% improvement
(but still ~15us instead of 5-6us).
In dhrystone: test results are the same.
There is also 2% improvement in boot time.

You can add me on CC list if you have some patches related to
this feature. I will give it a try on arm platforms.

Regards,
Lukasz

On 10/09/2018 07:29 PM, Waiman Long wrote:
> On 10/09/2018 11:39 AM, Lukasz Luba wrote:
>> This patch add some comment related to performance impact,
>> which can be really big (x3 times slower context switch).
>>
>> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
>> ---
>>   lib/Kconfig.debug | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index 4966c4f..9e67a2a3 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -1088,6 +1088,9 @@ config PROVE_LOCKING
>>   	 the proof of observed correctness is also maintained for an
>>   	 arbitrary combination of these separate locking variants.
>>   
>> +	 This feature enables LOCKDEP which can harm system performance
>> +	 even x3 times.
>> +
>>   	 For more details, see Documentation/locking/lockdep-design.txt.
>>   
>>   config LOCK_STAT
>> @@ -1112,6 +1115,10 @@ config LOCK_STAT
>>   	 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
>>   	 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
>>   
>> +	 This feature enables LOCKDEP which can harm system performance
>> +	 even x3 times.
>> +	 For more details, see Documentation/locking/lockdep-design.txt.
>> +
>>   config DEBUG_RT_MUTEXES
>>   	bool "RT Mutex debugging, deadlock detection"
>>   	depends on DEBUG_KERNEL && RT_MUTEXES
>> @@ -1175,6 +1182,10 @@ config DEBUG_LOCK_ALLOC
>>   	 spin_lock_init()/mutex_init()/etc., or whether there is any lock
>>   	 held during task exit.
>>   
>> +	 This feature enables LOCKDEP which can harm system performance
>> +	 even x3 times.
>> +	 For more details, see Documentation/locking/lockdep-design.txt.
>> +
>>   config LOCKDEP
>>   	bool
>>   	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
> 
> I don't mind seeing warning message about the performance impact of
> enabling lockdep. However, the actual slowdown depends on many factors
> including the type of systems, workloads and so on. I am a bit hesitant
> to quote an actual figure like x3 in the help text as it may not be
> correct in many cases.
> 
> BTW, my recent lockdep patch (https://lkml.org/lkml/2018/10/2/1410)
> should be able to reduce the performance impact of enabling lockdep.
> Could you try to see if that help in your case?
> 
> Cheers,
> Longman
> 
> 
> 
>