From: Ezequiel Garcia <elezegarcia@gmail.com> To: Minchan Kim <minchan@kernel.org> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Tim Bird <tim.bird@am.sony.com>, Pekka Enberg <penberg@kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Frederic Weisbecker <fweisbec@gmail.com>, Ingo Molnar <mingo@redhat.com> Subject: Re: [RFC/PATCH] scripts/tracing: Add trace_analyze.py tool Date: Wed, 23 Jan 2013 18:37:56 -0300 [thread overview] Message-ID: <CALF0-+V6D1Ka9SNyrgRAgTSGLUTp_9y4vYwauSx1qCfU-JOwjA@mail.gmail.com> (raw) In-Reply-To: <20130123042714.GD2723@blaptop> Hi Minchan, On Wed, Jan 23, 2013 at 1:27 AM, Minchan Kim <minchan@kernel.org> wrote: > Hi Ezequiel, > > On Tue, Jan 22, 2013 at 06:46:58AM -0300, Ezequiel Garcia wrote: >> From: Ezequiel Garcia <elezegarcia@gmail.com> >> >> The purpose of trace_analyze.py tool is to perform static >> and dynamic memory analysis using a kmem ftrace >> log file and a built kernel tree. >> >> This script and related work has been done on the CEWG/2012 project: >> "Kernel dynamic memory allocation tracking and reduction" >> (More info here [1]) >> >> It produces mainly two kinds of outputs: >> * an account-like output, similar to the one given by Perf, example below. >> * a ring-char output, examples here [2]. >> >> $ ./scripts/tracing/trace_analyze.py -k linux -f kmem.log --account-file account.txt >> $ ./scripts/tracing/trace_analyze.py -k linux -f kmem.log -c account.txt >> >> This will produce an account file like this: >> >> current bytes allocated: 669696 >> current bytes requested: 618823 >> current wasted bytes: 50873 >> number of allocs: 7649 >> number of frees: 2563 >> number of callers: 115 >> >> total waste net alloc/free caller >> --------------------------------------------- >> 299200 0 298928 1100/1 alloc_inode+0x4fL >> 189824 0 140544 1483/385 __d_alloc+0x22L >> 51904 0 47552 811/68 sysfs_new_dirent+0x4eL >> [...] >> >> [1] http://elinux.org/Kernel_dynamic_memory_analysis >> [2] http://elinux.org/Kernel_dynamic_memory_analysis#Current_dynamic_footprint > > First of all, Thanks for nice work! It could be very useful for > embedded side. > > Questions. > > 1. Can we detect different call path but same function? > I mean > > A C > \ / > B D > \ / > E > | > kmalloc > > In this case, E could be called by A or C. I would like to know the call path. > It could point out exact culprit of memory hogger. > I'm sorry, I'm not following you: How can I know which caller in the call path is the 'real' responsible for the allocation? The only way I can think of achieving something like this is by using kmalloc_track_caller() instead of kmalloc(). This is done in cases where an allocer is known to alloc memory on behalf of its caller. > 2. Does it support alloc_pages family? > kmem event trace already supports it. If it supports, maybe we can replace > CONFIG_PAGE_OWNER hack. > Mmm.. no, it doesn't support alloc_pages and friends, for we found no reason to do it. However, it sounds like a nice idea, on a first thought. I'll review CONFIG_PAGE_OWNER patches and see if I can come up with something. Meantime, and given this is just a script submission, is there anything preventing to merge this? We can move it to perf, and/or add it features, etc. later, on top of this. Does this make sense? -- Ezequiel
WARNING: multiple messages have this Message-ID (diff)
From: Ezequiel Garcia <elezegarcia@gmail.com> To: Minchan Kim <minchan@kernel.org> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Tim Bird <tim.bird@am.sony.com>, Pekka Enberg <penberg@kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Frederic Weisbecker <fweisbec@gmail.com>, Ingo Molnar <mingo@redhat.com> Subject: Re: [RFC/PATCH] scripts/tracing: Add trace_analyze.py tool Date: Wed, 23 Jan 2013 18:37:56 -0300 [thread overview] Message-ID: <CALF0-+V6D1Ka9SNyrgRAgTSGLUTp_9y4vYwauSx1qCfU-JOwjA@mail.gmail.com> (raw) In-Reply-To: <20130123042714.GD2723@blaptop> Hi Minchan, On Wed, Jan 23, 2013 at 1:27 AM, Minchan Kim <minchan@kernel.org> wrote: > Hi Ezequiel, > > On Tue, Jan 22, 2013 at 06:46:58AM -0300, Ezequiel Garcia wrote: >> From: Ezequiel Garcia <elezegarcia@gmail.com> >> >> The purpose of trace_analyze.py tool is to perform static >> and dynamic memory analysis using a kmem ftrace >> log file and a built kernel tree. >> >> This script and related work has been done on the CEWG/2012 project: >> "Kernel dynamic memory allocation tracking and reduction" >> (More info here [1]) >> >> It produces mainly two kinds of outputs: >> * an account-like output, similar to the one given by Perf, example below. >> * a ring-char output, examples here [2]. >> >> $ ./scripts/tracing/trace_analyze.py -k linux -f kmem.log --account-file account.txt >> $ ./scripts/tracing/trace_analyze.py -k linux -f kmem.log -c account.txt >> >> This will produce an account file like this: >> >> current bytes allocated: 669696 >> current bytes requested: 618823 >> current wasted bytes: 50873 >> number of allocs: 7649 >> number of frees: 2563 >> number of callers: 115 >> >> total waste net alloc/free caller >> --------------------------------------------- >> 299200 0 298928 1100/1 alloc_inode+0x4fL >> 189824 0 140544 1483/385 __d_alloc+0x22L >> 51904 0 47552 811/68 sysfs_new_dirent+0x4eL >> [...] >> >> [1] http://elinux.org/Kernel_dynamic_memory_analysis >> [2] http://elinux.org/Kernel_dynamic_memory_analysis#Current_dynamic_footprint > > First of all, Thanks for nice work! It could be very useful for > embedded side. > > Questions. > > 1. Can we detect different call path but same function? > I mean > > A C > \ / > B D > \ / > E > | > kmalloc > > In this case, E could be called by A or C. I would like to know the call path. > It could point out exact culprit of memory hogger. > I'm sorry, I'm not following you: How can I know which caller in the call path is the 'real' responsible for the allocation? The only way I can think of achieving something like this is by using kmalloc_track_caller() instead of kmalloc(). This is done in cases where an allocer is known to alloc memory on behalf of its caller. > 2. Does it support alloc_pages family? > kmem event trace already supports it. If it supports, maybe we can replace > CONFIG_PAGE_OWNER hack. > Mmm.. no, it doesn't support alloc_pages and friends, for we found no reason to do it. However, it sounds like a nice idea, on a first thought. I'll review CONFIG_PAGE_OWNER patches and see if I can come up with something. Meantime, and given this is just a script submission, is there anything preventing to merge this? We can move it to perf, and/or add it features, etc. later, on top of this. Does this make sense? -- Ezequiel -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-01-23 21:38 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-22 9:46 [RFC/PATCH] scripts/tracing: Add trace_analyze.py tool Ezequiel Garcia 2013-01-22 9:46 ` Ezequiel Garcia 2013-01-22 13:41 ` Pekka Enberg 2013-01-22 13:41 ` Pekka Enberg 2013-01-22 16:16 ` Ezequiel Garcia 2013-01-22 16:16 ` Ezequiel Garcia 2013-01-23 4:27 ` Minchan Kim 2013-01-23 4:27 ` Minchan Kim 2013-01-23 21:37 ` Ezequiel Garcia [this message] 2013-01-23 21:37 ` Ezequiel Garcia 2013-01-24 5:50 ` Minchan Kim 2013-01-24 5:50 ` Minchan Kim 2013-01-24 17:16 ` Ezequiel Garcia 2013-01-24 17:16 ` Ezequiel Garcia 2013-01-24 23:24 ` Minchan Kim 2013-01-24 23:24 ` Minchan Kim
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CALF0-+V6D1Ka9SNyrgRAgTSGLUTp_9y4vYwauSx1qCfU-JOwjA@mail.gmail.com \ --to=elezegarcia@gmail.com \ --cc=ezequiel.garcia@free-electrons.com \ --cc=fweisbec@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=minchan@kernel.org \ --cc=mingo@redhat.com \ --cc=penberg@kernel.org \ --cc=rostedt@goodmis.org \ --cc=tim.bird@am.sony.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.