Messages in this thread | | | Subject | Re: BUG: MAX_STACK_TRACE_ENTRIES too low! (2) | From | Bart Van Assche <> | Date | Fri, 12 Jul 2019 16:03:18 -0700 |
| |
On 7/12/19 1:55 AM, Peter Zijlstra wrote: > On Thu, Jul 11, 2019 at 11:53:12AM -0700, Bart Van Assche wrote: >> On 7/10/19 3:09 PM, Peter Zijlstra wrote: >>> One thing I mentioned when Thomas did the unwinder API changes was >>> trying to move lockdep over to something like stackdepot. >>> >>> We can't directly use stackdepot as is, because it uses locks and memory >>> allocation, but we could maybe add a lower level API to it and use that >>> under the graph_lock() on static storage or something. >>> >>> Otherwise we'll have to (re)implement something like it. >>> >>> I've not looked at it in detail. >> >> Hi Peter, >> >> Is something like the untested patch below perhaps what you had in mind? > > Most excellent, yes! Now I suppose the $64000 question is if it actually > reduces the amount of storage we use for stack traces.. > > Seems to boot just fine.. :-)
Hi Peter,
On my setup after some time the space occupied by stack traces stabilizes to the following:
# grep stack /proc/lockdep_stats stack-trace entries: 169456 [max: 524288] number of stack traces: 9073 number of stack hash chains: 6980
I think these numbers show that there are some but not too many hash collisions (the code for the hash statistics was added after I e-mailed my patch).
Bart.
| |