perf record: Release resources at exit
in [Kernel]
|
Prev: [PATCH v2 0/3] MAX8998 changes for RTC
Next: [PATCH v2 1/3] mfd: MAX8998: Use struct i2c_client to argument on i2c operation functions
From: Nick Piggin on 2 Aug 2010 07:20 On Mon, Aug 02, 2010 at 11:17:14AM +0200, Ingo Molnar wrote: > > * Nick Piggin <npiggin(a)suse.de> wrote: > > > On Mon, Aug 02, 2010 at 09:54:22AM +0200, Ingo Molnar wrote: > > > > > > * Nick Piggin <npiggin(a)suse.de> wrote: > > > > > > That's certainly true but there's no valgrind crappiness here: valgrind simply > > > can do a better job of finding leaks if there's a well defined "all resources > > > the app still knows about are freed now" point. > > > > "noise" sounds like false positives though. [...] > > Every predictive bug detection scheme is open to the potential of false > positives. I've yet to see a complex one that is 100% false positive free. So long as false positive noise can be easily avoided in running of the automated testing -- ie. not worked around in the software -- then this is totally fine of course. > > [...] Certainly if this is instead allows valgrind to run in a particular > > mode that assumes no application resources consumed at exit(2) time, I > > wouldn't call it crappy :) > > Most apps free their stuff before they exit - i do it in all my own C apps. > > That is generally useful: for example it makes it easier to thread a program > later on - when exit() becomes pthread_exit() and a silent leak turns into a > real leak. > > Hence Valgrind checking for exit() by default looks useful to me. Sure, most of the time I would too (in fact, all the time seeing as I don't write non-trivial user programs). But when you're doing last pass optimisations, it would be very reasonable to avoid things like teardown of complex data structures. > > But you could equally sprinkle in other valgrind specific annotations or > > semantics at various points in the code to improve its coverage, no? > > Yeah, and exit() sounds like a pretty convenient point, right? That's the > point where all resources are inactive hence a scan for leaks is expected to > be the most efficient in finding real leaks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 2 Aug 2010 11:00
Em Mon, Aug 02, 2010 at 07:59:47PM +1000, Nick Piggin escreveu: > On Mon, Aug 02, 2010 at 11:17:14AM +0200, Ingo Molnar wrote: > > Most apps free their stuff before they exit - i do it in all my own C apps. > > > > That is generally useful: for example it makes it easier to thread a program > > later on - when exit() becomes pthread_exit() and a silent leak turns into a > > real leak. Right, part of my goal was exactly the potential librarization of nowaday main routines of builtin commands. > > Hence Valgrind checking for exit() by default looks useful to me. > > Sure, most of the time I would too (in fact, all the time seeing as > I don't write non-trivial user programs). But when you're doing last > pass optimisations, it would be very reasonable to avoid things like > teardown of complex data structures. Yeah, I thought about having some test to only do the on-exit destruction of lots of rbtrees if in debugging mode, and I may end up doing it at some point. But on another angle, right now I think we really need to more aggressively delete stuff (like maps that had no hits on PERF_RECORD_EXIT'ed threads and thus have no reference on any hist_entry instance) to support huge perf.data file buildid exit processing. So part of the goal was that: no leaks left behind policy. That is, till the day when we stash the 20 byte buildid in the per binary image loaded kernel data structure so that we can have it in the PERF_RECORD_MMAP and avoid all this processing at exit, and instead do it taking advantage of the existing noise at loading time. 8-) - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |