From: Andrew Morton <akpm@linux-foundation.org>
To: Stefani Seibold <stefani@seibold.net>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, mingo@elte.hu,
joern@logfs.org, tglx@linutronix.de
Subject: Re: Detailed Stack Information Patch Next Generation
Date: Wed, 3 Jun 2009 14:06:40 -0700 [thread overview]
Message-ID: <20090603140640.429528c1.akpm@linux-foundation.org> (raw)
In-Reply-To: <1244061249.5624.62.camel@wall-e>
> Subject: Detailed Stack Information Patch Next Generation
That's not a very useful patch title. Something like
[patch] procfs: provide stack information for threads
would suit.
On Wed, 03 Jun 2009 22:34:09 +0200
Stefani Seibold <stefani@seibold.net> wrote:
> Hi everybody,
>
> kernel 2.6.30 is near so i think it is time for the next try.
>
> This is the new version of the "detailed stack info" patch which give
> you a better overview of the userland application stack usage,
> especially for embedded linux.
>
> Currently you are only able to dump the main process/thread stack usage
> which is showed in /proc/pid/status by the "VmStk" Value. But you get no
> information about the consumed stack memory of the the threads.
>
> There is an enhancement in the /proc/<pid>/{task/*,}/*maps and which
> marks the vm mapping where the thread stack pointer reside with "[thread
> stack xxxxxxxx]". xxxxxxxx is the start address of the stack.
>
> Also there is a new entry "stack usage" in /proc/<pid>/{task/*,}/status
> which will you give the current stack usage in kb.
>
> I also fixed stack base address in /proc/<pid>/task/*/stat to the base
> address of the associated thread stack and not the one of the main
> process. This makes more sense.
>
> Changes since last posting:
>
> - Redesigned everything what was suggested by Ingo
> - the thread watch monitor is gone
> - the /proc/stackmon entry is also gone
> - slime done
>
> The patch is against 2.6.30-rc7 and tested with on intel and ppc
> architectures.
>
> I think it is now ready for inclusion in the main kernel. Ingo what do
> you think?
>
Missing Signed-off-by:
>
> fs/exec.c | 2 +
> fs/proc/array.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++-
> fs/proc/task_mmu.c | 14 ++++++++++
> include/linux/sched.h | 1
> kernel/fork.c | 3 ++
> 5 files changed, 88 insertions(+), 1 deletion(-)
>
> -patch begins here--------------------------------------------------------------
>
> diff -u -N -r linux-2.6.30.orig/fs/exec.c linux-2.6.30/fs/exec.c
> --- linux-2.6.30.orig/fs/exec.c 2009-06-03 17:36:41.000000000 +0200
> +++ linux-2.6.30/fs/exec.c 2009-06-03 17:30:47.000000000 +0200
> @@ -1328,6 +1328,8 @@
> if (retval < 0)
> goto out;
>
> + current->stack_start = current->mm->start_stack;
> +
> /* execve succeeded */
> current->fs->in_exec = 0;
> current->in_execve = 0;
> diff -u -N -r linux-2.6.30.orig/fs/proc/array.c linux-2.6.30/fs/proc/array.c
> --- linux-2.6.30.orig/fs/proc/array.c 2009-06-03 17:36:41.000000000 +0200
> +++ linux-2.6.30/fs/proc/array.c 2009-06-03 17:32:53.000000000 +0200
> @@ -82,6 +82,7 @@
> #include <linux/pid_namespace.h>
> #include <linux/ptrace.h>
> #include <linux/tracehook.h>
> +#include <linux/pfn.h>
>
> #include <asm/pgtable.h>
> #include <asm/processor.h>
> @@ -321,6 +322,71 @@
> p->nivcsw);
> }
>
> +#ifdef CONFIG_STACK_GROWSUP
> +static inline unsigned long get_stack_pages(struct vm_area_struct *vma,
> + struct task_struct *p)
> +{
> + unsigned long i;
> + struct page *page;
> + unsigned long stack_usage;
> + unsigned long esp;
It's unclear what the units are here. Are they in bytes? Pages? Code
comments and well-chosen identifiers are the way to fix this.
> + esp = KSTK_ESP(p);
So `esp' is in bytes.
> + stack_usage = (PFN_ALIGN(esp)-PFN_ALIGN(p->stack_start));
And `stack_usage' measures bytes
> + for (i = vma->vm_end; i-PAGE_SIZE > esp; i -= PAGE_SIZE) {
And `i' measures bytes
> + page = follow_page(vma, i-PAGE_SIZE, 0);
> +
> + if ((!IS_ERR(page) == 0) || (page))
Why not simply
if (IS_ERR(page) || page)
?
And shouldn't it be !page?
> + break;
> + }
> + return ((i - esp + stack_usage) >> (PAGE_SHIFT)) + 1;
And we return a number-of-pages. Fair enough.
> +}
> +#else
> +static inline unsigned long get_stack_pages(struct vm_area_struct *vma,
> + struct task_struct *p)
> +{
> + unsigned long i;
> + struct page *page;
> + unsigned long stack_usage;
> + unsigned long esp;
> +
> + esp = KSTK_ESP(p);
> +
> + stack_usage = (PFN_ALIGN(p->stack_start) - PFN_ALIGN(esp));
> +
> + for (i = vma->vm_start; i+PAGE_SIZE <= esp; i += PAGE_SIZE) {
> +
> + page = follow_page(vma, i, 0);
> +
> + if ((!IS_ERR(page) == 0) || (page))
> + break;
> + }
> + return ((esp - i + stack_usage) >> (PAGE_SHIFT)) + 1;
> +}
Dittoes.
> +#endif
> +
> +static inline void task_show_stack_usage(struct seq_file *m,
> + struct task_struct *p)
> +{
> + struct vm_area_struct *vma;
> + struct mm_struct *mm;
> +
> + mm = get_task_mm(p);
> +
> + if (mm) {
> + vma = find_vma(mm, p->stack_start);
> +
> + if (vma)
> + seq_printf(m, "Stack usage:\t%lu kB\n",
> + get_stack_pages(vma, p) << (PAGE_SHIFT - 10));
So get_stack_pages() did a bytes-to-pages conversion then its sole
caller does a pages-to-bytes conversion. Can this be simplified?
> +
> + mmput(mm);
> + }
> +}
>
> int proc_pid_status(struct seq_file *m, struct pid_namespace *ns,
> struct pid *pid, struct task_struct *task)
> {
> @@ -340,6 +406,7 @@
> task_show_regs(m, task);
> #endif
> task_context_switch_counts(m, task);
> + task_show_stack_usage(m, task);
> return 0;
> }
>
> @@ -481,7 +548,7 @@
> rsslim,
> mm ? mm->start_code : 0,
> mm ? mm->end_code : 0,
> - (permitted && mm) ? mm->start_stack : 0,
> + (permitted) ? task->stack_start : 0,
> esp,
> eip,
> /* The signal information here is obsolete.
> diff -u -N -r linux-2.6.30.orig/fs/proc/task_mmu.c linux-2.6.30/fs/proc/task_mmu.c
> --- linux-2.6.30.orig/fs/proc/task_mmu.c 2009-06-03 17:36:41.000000000 +0200
> +++ linux-2.6.30/fs/proc/task_mmu.c 2009-06-03 17:30:47.000000000 +0200
> @@ -242,6 +242,20 @@
> } else if (vma->vm_start <= mm->start_stack &&
> vma->vm_end >= mm->start_stack) {
> name = "[stack]";
> + } else {
> + unsigned long stack_start;
> +
> + stack_start =
> + ((struct proc_maps_private *)
> + m->private)->task->stack_start;
Like this:
unsiged long stack_start;
struct proc_maps_private *pmp;
pmp = m->private;
stack_start = pmp->task->stack_start;
> + if (vma->vm_start <= stack_start &&
> + vma->vm_end >= stack_start) {
> + pad_len_spaces(m, len);
> + seq_printf(m,
> + "[thread stack: %08lx]",
> + stack_start);
> + }
> }
> } else {
> name = "[vdso]";
> diff -u -N -r linux-2.6.30.orig/include/linux/sched.h linux-2.6.30/include/linux/sched.h
> --- linux-2.6.30.orig/include/linux/sched.h 2009-06-03 17:36:41.000000000 +0200
> +++ linux-2.6.30/include/linux/sched.h 2009-06-03 17:30:47.000000000 +0200
> @@ -1429,6 +1429,7 @@
> /* state flags for use by tracers */
> unsigned long trace;
> #endif
> + unsigned long stack_start;
> };
>
> /* Future-safe accessor for struct task_struct's cpus_allowed. */
> diff -u -N -r linux-2.6.30.orig/kernel/fork.c linux-2.6.30/kernel/fork.c
> --- linux-2.6.30.orig/kernel/fork.c 2009-06-03 17:36:42.000000000 +0200
> +++ linux-2.6.30/kernel/fork.c 2009-06-03 17:30:47.000000000 +0200
> @@ -1092,6 +1092,9 @@
> if (unlikely(current->ptrace))
> ptrace_fork(p, clone_flags);
>
> + p->stack_start = (stack_start == KSTK_ESP(current)) ?
> + current->stack_start : stack_start;
> +
hm. What's this doing?
--
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:[~2009-06-03 21:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-31 14:58 Detailed Stack Information Patch [1/3] Stefani Seibold
2009-04-01 19:31 ` Ingo Molnar
2009-04-02 21:26 ` Stefani Seibold
2009-06-03 20:34 ` Detailed Stack Information Patch Next Generation Stefani Seibold
2009-06-03 21:06 ` Andrew Morton [this message]
2009-06-04 11:23 ` [patch] procfs: provide stack information for threads Stefani Seibold
2009-06-04 11:37 ` Andrew Morton
2009-06-04 11:56 ` Stefani Seibold
2009-06-04 17:57 ` Andrew Morton
2009-06-04 20:21 ` Stefani Seibold
2009-06-04 21:23 ` Andrew Morton
2009-06-05 19:12 ` Stefani Seibold
2009-06-05 19:19 ` Andrew Morton
2009-10-02 21:17 ` Andreas Schwab
2009-10-02 21:44 ` Andreas Schwab
2009-10-03 6:47 ` Andreas Schwab
2009-10-03 7:40 ` Stefani Seibold
2009-10-03 11:33 ` Stefani Seibold
2009-06-06 10:01 ` [patch] procfs: provide stack information for threads V0.6 Stefani Seibold
2009-06-09 10:35 ` [patch] proc.txt: Update kernel filesystem/proc.txt documentation Stefani Seibold
2009-06-09 19:36 ` Andrew Morton
2009-06-09 20:53 ` Stefani Seibold
2009-06-09 21:13 ` Andrew Morton
2009-06-10 6:46 ` [patch 1/2] " Stefani Seibold
2009-06-10 6:46 ` [patch 2/2] procfs: provide stack information for threads V0.7 Stefani Seibold
2009-06-10 7:20 ` [patch 2/2] procfs: provide stack information for threads V0.8 Stefani Seibold
2009-06-15 22:01 ` Andrew Morton
2009-06-16 7:14 ` Stefani Seibold
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=20090603140640.429528c1.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=joern@logfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=stefani@seibold.net \
--cc=tglx@linutronix.de \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).