Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1645243 > unrolled thread

[PATCH] lockdep: do not count lock class operations without CONFIG_DEBUG_LOCKDEP

Started byKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
First post2017-05-19 09:10 +0200
Last post2017-05-19 11:30 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] lockdep: do not count lock class operations without  CONFIG_DEBUG_LOCKDEP Konstantin Khlebnikov <khlebnikov@yandex-team.ru> - 2017-05-19 09:10 +0200
    Re: [PATCH] lockdep: do not count lock class operations without  CONFIG_DEBUG_LOCKDEP Peter Zijlstra <peterz@infradead.org> - 2017-05-19 11:10 +0200
      Re: [PATCH] lockdep: do not count lock class operations without  CONFIG_DEBUG_LOCKDEP Konstantin Khlebnikov <khlebnikov@yandex-team.ru> - 2017-05-19 11:30 +0200

#1645243 — [PATCH] lockdep: do not count lock class operations without CONFIG_DEBUG_LOCKDEP

FromKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date2017-05-19 09:10 +0200
Subject[PATCH] lockdep: do not count lock class operations without CONFIG_DEBUG_LOCKDEP
Message-ID<tIKcW-76X-5@gated-at.bofh.it>
Currently this counter shown in /proc/lockdep if CONFIG_DEBUG_LOCKDEP=y
This patch disables it completely if this option is disabled.

This counter might be useful for debugging lockdep itself, but for normal
debugging it seems useless. Lockstat provides more detailed statistics.

This atomic_inc is a hot spot inside __lock_acquire() for debug kernel.

With patch "netperf -H localhost" shows some boost: 2500 -> 2600

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
---
 kernel/locking/lockdep.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index c0e31bfee25c..60bd16984546 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1375,7 +1375,9 @@ static void print_lock_class_header(struct lock_class *class, int depth)
 
 	printk("%*s->", depth, "");
 	print_lock_name(class);
+#ifdef CONFIG_DEBUG_LOCKDEP
 	printk(KERN_CONT " ops: %lu", class->ops);
+#endif
 	printk(KERN_CONT " {\n");
 
 	for (bit = 0; bit < LOCK_USAGE_STATES; bit++) {
@@ -3256,7 +3258,9 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
 		if (!class)
 			return 0;
 	}
+#ifdef CONFIG_DEBUG_LOCKDEP
 	atomic_inc((atomic_t *)&class->ops);
+#endif
 	if (very_verbose(class)) {
 		printk("\nacquire class [%p] %s", class->key, class->name);
 		if (class->name_version > 1)

[toc] | [next] | [standalone]


#1645423

FromPeter Zijlstra <peterz@infradead.org>
Date2017-05-19 11:10 +0200
Message-ID<tIM55-8nS-39@gated-at.bofh.it>
In reply to#1645243
On Fri, May 19, 2017 at 10:06:01AM +0300, Konstantin Khlebnikov wrote:
> Currently this counter shown in /proc/lockdep if CONFIG_DEBUG_LOCKDEP=y
> This patch disables it completely if this option is disabled.
> 
> This counter might be useful for debugging lockdep itself, but for normal
> debugging it seems useless. Lockstat provides more detailed statistics.
> 
> This atomic_inc is a hot spot inside __lock_acquire() for debug kernel.
> 
> With patch "netperf -H localhost" shows some boost: 2500 -> 2600

Nothing against these patches, but I do wonder why you're performance
optimizing debug kernels ;-)

[toc] | [prev] | [next] | [standalone]


#1645460

FromKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date2017-05-19 11:30 +0200
Message-ID<tIMoq-8v4-13@gated-at.bofh.it>
In reply to#1645423
On 19.05.2017 12:09, Peter Zijlstra wrote:
> On Fri, May 19, 2017 at 10:06:01AM +0300, Konstantin Khlebnikov wrote:
>> Currently this counter shown in /proc/lockdep if CONFIG_DEBUG_LOCKDEP=y
>> This patch disables it completely if this option is disabled.
>>
>> This counter might be useful for debugging lockdep itself, but for normal
>> debugging it seems useless. Lockstat provides more detailed statistics.
>>
>> This atomic_inc is a hot spot inside __lock_acquire() for debug kernel.
>>
>> With patch "netperf -H localhost" shows some boost: 2500 -> 2600
> 
> Nothing against these patches, but I do wonder why you're performance
> optimizing debug kernels ;-)
> 

Performance of debug features matters too
Obviously this saves time and money for massive testing

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web