Tuning Valgrind For Your Workload PDF (slides)
Contents
1. Tuning Valgrind for your Workload Hints tricks and tips to effectively use Valgrind on small or big applications Philippe Waroquiers FOSDEM 2015 valgrind devroom Some rumours about Valgrind e Valgrind burns all the CPU it can e and it burns it on a single CORE e Valgrind eats memory as much as it can e Valgrind is powerful and sophisticated it finds nasty bugs and gives you a lot of information about your bugs and your program e Last rumour Is true e First 3 rumours are also Somewhat true 2 Valgrind resource consumption e To give sophisticated functionalities Valgrind is effectively a big resource consumer e Can we do something about that e Yes we can e Simple use default tool and default options valgrind your_program e Otherwise valgrind and all its tools have more than 150 user command line options to e g control what kind of bugs to detect which information to capture Valgrind resource consumption what can we do e Use command line options to e consume even more CPU memory and have more information features e decrease Somewhat CPU memory consumption by reducing captured information e What can be controlled can be e Tool independent e g stacktrace size use of debug information e Tool dependent e g uninitialised memory origin tracking for memcheck detailed race condition history for helgrind Demo Tuning Valgrind malloc replacement e Red zones useful2. ef value errors no memcheck track lockorders no helgrind Tune stack recording Decrease redzone size redzone size N Decrease num transtab sectors Study valgrind help and valgrind user manual Optimising Valgrind for functionality e Enable optional tool functionalities e g track origin yes memcheck leak check heuristics all memcheck e Record more all what you can e g memcheck freelist VOl NNNNN keep stacktraces alloc and free e study valgrind help and valgrind user manual Conclusions guidelines e Default options are ok for an average user e gt automate your regression tests e gt run them under Valgrind and be patient e Read Valgrind manual e You have nice optional features to activate e You can Somewhat tune valgrind for your workload Questions
3. onfigure the size of the full history cache Obtaining more info about your bugs Default values for Valgrind options are chosen to provide a good balance between cost CPU and memory and provided functionality e Examples read inline info yes read var info no track origins no memcheck history level full helgrind Tuning Valgrind JIT e You might unlikely gain a few by using the VEX command line options e Use valgrind help debug for details e If your application code Is big e You might avoid re translating code by increasing valgrind JIT code cache num transtab sectors NN impacts memory e Use stats yes to see when a transtab sector is recycled Getting Valgrind info stats e Use valgrind stats yes v v for general stats e Use valgrind profile heap yes for detailed internal valgrind memory use e During run you can use from shell e vgdb v info stats e vgdb v info memory aspacemgr Optimising Valgrind for soeed CPU Set your CPU frequency to fixed high speed e e g using cpufreq selector g performance Tune stack recording e g if heavy malloc use If huge code increase num transtab sectors Disable some tool specific features e g undef value errors no memcheck track lockorders no helgrind Unlikely limited gain using vex options Study valgrind help and valgrind user manual Optimising Valgrind for memory Disable some tool specific features e g und
4. to detect over under run e Configurable via redzone size xxxx e But are costly if many small blocks e gt Reduce redzone size if short on memory In particular for helgrind e gt Increase redzone size if suspecting big over under run e Use stats yes v v to have some useful info about the valgrind malloc arenas Tuning Valgrind stacktrace capture Configure the nr of recorded program counters num callers xx To merge recursive calls merge recursive frames x valgrind gt 3 10 shows inlined calls unless you give read inline info no To have stats about recorded stack traces valgrind stats yes 2 gt amp 1 grep exectx For full list use gdo vgdb monitor command gdb monitor v info exectxt Tuning Valgrind stacktrace capture memcheck specific e By default one stack trace Is referenced e memcheck records both malloc and free stack trace e A block references the last recorded stack trace the malloc stack trace and when freed the free stacktrace e Use keep stacktraces to control what to record and reference keep stacktraces alloc and free only one word overhead per block compared to keep stacktraces alloc then free Tuning Valgrind stacktrace capture helgrind specific e By default helgrind keeps a stacktrace max 8 frames for past memory accesses e Use history level none approx full to control what history stacktraces to record e Use conflict cache size N to c
Download Pdf Manuals
Related Search