As Peter has put it all sound and complete for the cause, I simply quote:

"It (check_redundant) was added for cross-release (which has since been
reverted) which would generate a lot of redundant links (IIRC) but
having it makes the reports more convoluted -- basically, if we had an
A-B-C relation, then A-C will not be added to the graph because it is
already covered. This then means any report will include B, even though
a shorter cycle might have been possible."

This would increase the number of direct dependencies. For a simple workload
(make clean; reboot; make vmlinux -j8), the data looks like this:

 CONFIG_LOCKDEP_SMALL: direct dependencies:                  6926

!CONFIG_LOCKDEP_SMALL: direct dependencies:                  9052    (+30.7%)

Suggested-by: Peter Zijlstra (Intel) <pet...@infradead.org>
Signed-off-by: Yuyang Du <duyuy...@gmail.com>
---
 kernel/locking/lockdep.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 2502ea4..9d2728c 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1734,6 +1734,7 @@ unsigned long lockdep_count_backward_deps(struct 
lock_class *class)
        return ret;
 }
 
+#ifdef CONFIG_LOCKDEP_SMALL
 /*
  * Check that the dependency graph starting at <src> can lead to
  * <target> or not. If it can, <src> -> <target> dependency is already
@@ -1763,6 +1764,7 @@ unsigned long lockdep_count_backward_deps(struct 
lock_class *class)
 
        return ret;
 }
+#endif
 
 #ifdef CONFIG_TRACE_IRQFLAGS
 
@@ -2423,12 +2425,14 @@ static inline void inc_chains(void)
                }
        }
 
+#ifdef CONFIG_LOCKDEP_SMALL
        /*
         * Is the <prev> -> <next> link redundant?
         */
        ret = check_redundant(prev, next);
        if (ret != 1)
                return ret;
+#endif
 
        if (!trace->nr_entries && !save_trace(trace))
                return 0;
-- 
1.8.3.1

Reply via email to