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 03:40 On Sun, Aug 01, 2010 at 10:08:46PM -0300, Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo <acme(a)redhat.com> > > So that we can reduce the noise on valgrind when looking for memory > leaks. Really? That's rather crappy of valgrind. exit is well defined to release resources and that's often a more efficient way to do it It finds and batches things a lot better, eg. it can avoid all TLB flushing of freeing memory that munmap requires. -- 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: Ingo Molnar on 2 Aug 2010 04:00 * Nick Piggin <npiggin(a)suse.de> wrote: > On Sun, Aug 01, 2010 at 10:08:46PM -0300, Arnaldo Carvalho de Melo wrote: > > From: Arnaldo Carvalho de Melo <acme(a)redhat.com> > > > > So that we can reduce the noise on valgrind when looking for memory > > leaks. > > Really? That's rather crappy of valgrind. exit is well defined to release > resources and that's often a more efficient way to do it It finds and > batches things a lot better, eg. it can avoid all TLB flushing of freeing > memory that munmap requires. 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. The _kernel_ obviously can release all resources. The distinction is between 'resources known to the app' and 'all resources'. That set contains the leaking resources. Thanks, Ingo -- 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: Nick Piggin on 2 Aug 2010 04:10 On Mon, Aug 02, 2010 at 09:54:22AM +0200, Ingo Molnar wrote: > > * Nick Piggin <npiggin(a)suse.de> wrote: > > > On Sun, Aug 01, 2010 at 10:08:46PM -0300, Arnaldo Carvalho de Melo wrote: > > > From: Arnaldo Carvalho de Melo <acme(a)redhat.com> > > > > > > So that we can reduce the noise on valgrind when looking for memory > > > leaks. > > > > Really? That's rather crappy of valgrind. exit is well defined to release > > resources and that's often a more efficient way to do it It finds and > > batches things a lot better, eg. it can avoid all TLB flushing of freeing > > memory that munmap requires. > > 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. 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 :) But you could equally sprinkle in other valgrind specific annotations or semantics at various points in the code to improve its coverage, no? -- 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: Pekka Enberg on 2 Aug 2010 04:10 On Mon, Aug 2, 2010 at 4:08 AM, Arnaldo Carvalho de Melo <acme(a)infradead.org> wrote: > From: Arnaldo Carvalho de Melo <acme(a)redhat.com> > > So that we can reduce the noise on valgrind when looking for memory > leaks. > > Cc: Frederic Weisbecker <fweisbec(a)gmail.com> > Cc: Mike Galbraith <efault(a)gmx.de> > Cc: Peter Zijlstra <peterz(a)infradead.org> > Cc: Stephane Eranian <eranian(a)google.com> > LKML-Reference: <new-submission> > Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Yes, please. Acked-by: Pekka Enberg <penberg(a)cs.helsinki.fi> -- 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: Ingo Molnar on 2 Aug 2010 05:20
* 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: > > > > > On Sun, Aug 01, 2010 at 10:08:46PM -0300, Arnaldo Carvalho de Melo wrote: > > > > From: Arnaldo Carvalho de Melo <acme(a)redhat.com> > > > > > > > > So that we can reduce the noise on valgrind when looking for memory > > > > leaks. > > > > > > Really? That's rather crappy of valgrind. exit is well defined to release > > > resources and that's often a more efficient way to do it It finds and > > > batches things a lot better, eg. it can avoid all TLB flushing of freeing > > > memory that munmap requires. > > > > 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. > [...] 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. > 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. Thanks, Ingo -- 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/ |