Messages in this thread | | | Subject | Re: MAX_LOCKDEP_ENTRIES too low (called from ioc_release_fn) | From | Peter Zijlstra <> | Date | Fri, 19 Oct 2012 14:49:32 +0200 |
| |
On Fri, 2012-10-19 at 01:21 -0400, Dave Jones wrote: > > Not sure why you are CC'ing a call site, rather than the maintainers of > > the code. Just looks like lockdep is using too small a static value. > > Though it is pretty darn large... > > You're right, it's a huge chunk of memory. > It looks like I can trigger this from multiple callsites.. > Another different trace below. > > Not sure why this suddenly got a lot worse in 3.7
Did we add a static array of structures with locks in somewhere? Doing that is a great way of blowing up the number of lock classes and the resulting amount of lock dependency chains.
From Documentation/lockdep-design.txt; it talks about overflowing MAX_LOCKDEP_KEYS, but I suppose its a good starts for overflowing the dependency entries too, more classes means more dependencies after all.
--- Of course, if you do run out of lock classes, the next thing to do is to find the offending lock classes. First, the following command gives you the number of lock classes currently in use along with the maximum:
grep "lock-classes" /proc/lockdep_stats
This command produces the following output on a modest system:
lock-classes: 748 [max: 8191]
If the number allocated (748 above) increases continually over time, then there is likely a leak. The following command can be used to identify the leaking lock classes:
grep "BD" /proc/lockdep
Run the command and save the output, then compare against the output from a later run of this command to identify the leakers. This same output can also help you find situations where runtime lock initialization has been omitted.
| |