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