Messages in this thread | | | Subject | Re: [PATCH v3] lockdep: Make MAX_STACK_TRACE_ENTRIES configurable. | From | Peter Zijlstra <> | Date | Wed, 21 Apr 2010 14:03:00 +0200 |
| |
On Wed, 2010-04-21 at 05:47 -0600, Gregory Haskins wrote: > > I am not sure if Johns solution is the right/best one per se, but I can attest > that I used to hit this problem _all_ the time and it was somewhat annoying > to need to patch the kernel on all of my machines to fix it. I realize that I > perhaps do not represent the average user, but it was a pain-point for me. > FWIW, John's patch would indeed make my life easier since I tend to share the > .config between builds.
Right, so all I'm wanting to know if its a symptom of some funny or an actual depletion, in the latter case I think the best solution is to simply increase the number. In the former case we should of course fix the real issue instead of making it disappear.
So one case I remember is where some code managed to create 1k classes where 1 would have sufficed, this resulted in at least 1k extra stack traces to be stored, consuming vast amounts of stack_entries.
So please, if you can reproduce, look at where these entries are going, lots of classes with the same name are a good hint that something is fishy. Classes with more than 13 (4*nr_states + 1) stacks should also never happen, etc..
Is this specific to -RT, or do we see it without as well? If so, what in -RT grows this? Are we creating a class per rt_mutex spinlock or something silly like that?
| |