remarkable-linux/fs/proc
Stefani Seibold d899bf7b55 procfs: provide stack information for threads
A patch to give 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 maximum size of stack.  This is a value
information, because libpthread doesn't set the start of the stack to the
top of the mapped area, depending of the pthread usage.

A sample output of /proc/<pid>/task/<tid>/maps looks like:

08048000-08049000 r-xp 00000000 03:00 8312       /opt/z
08049000-0804a000 rw-p 00001000 03:00 8312       /opt/z
0804a000-0806b000 rw-p 00000000 00:00 0          [heap]
a7d12000-a7d13000 ---p 00000000 00:00 0
a7d13000-a7f13000 rw-p 00000000 00:00 0          [thread stack: 001ff4b4]
a7f13000-a7f14000 ---p 00000000 00:00 0
a7f14000-a7f36000 rw-p 00000000 00:00 0
a7f36000-a8069000 r-xp 00000000 03:00 4222       /lib/libc.so.6
a8069000-a806b000 r--p 00133000 03:00 4222       /lib/libc.so.6
a806b000-a806c000 rw-p 00135000 03:00 4222       /lib/libc.so.6
a806c000-a806f000 rw-p 00000000 00:00 0
a806f000-a8083000 r-xp 00000000 03:00 14462      /lib/libpthread.so.0
a8083000-a8084000 r--p 00013000 03:00 14462      /lib/libpthread.so.0
a8084000-a8085000 rw-p 00014000 03:00 14462      /lib/libpthread.so.0
a8085000-a8088000 rw-p 00000000 00:00 0
a8088000-a80a4000 r-xp 00000000 03:00 8317       /lib/ld-linux.so.2
a80a4000-a80a5000 r--p 0001b000 03:00 8317       /lib/ld-linux.so.2
a80a5000-a80a6000 rw-p 0001c000 03:00 8317       /lib/ld-linux.so.2
afaf5000-afb0a000 rw-p 00000000 00:00 0          [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]

Also there is a new entry "stack usage" in /proc/<pid>/{task/*,}/status
which will you give the current stack usage in kb.

A sample output of /proc/self/status looks like:

Name:	cat
State:	R (running)
Tgid:	507
Pid:	507
.
.
.
CapBnd:	fffffffffffffeff
voluntary_ctxt_switches:	0
nonvoluntary_ctxt_switches:	0
Stack usage:	12 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.

[akpm@linux-foundation.org: fs/proc/array.c now needs walk_page_range()]
Signed-off-by: Stefani Seibold <stefani@seibold.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-23 07:39:41 -07:00
..
array.c procfs: provide stack information for threads 2009-09-23 07:39:41 -07:00
base.c fs/proc/base.c: fix proc_fault_inject_write() input sanity check 2009-09-23 07:39:40 -07:00
cmdline.c
cpuinfo.c
devices.c
generic.c
inode.c
internal.h Move junk from proc_fs.h to fs/proc/internal.h 2009-06-11 21:36:01 -04:00
interrupts.c
Kconfig
kcore.c kcore: fix /proc/kcore's stat.st_size 2009-09-23 07:39:40 -07:00
kmsg.c
loadavg.c
Makefile proc: export statistics for softirq to /proc 2009-06-18 13:03:41 -07:00
meminfo.c mm: oom analysis: add shmem vmstat 2009-09-22 07:17:27 -07:00
mmu.c
nommu.c seq_file: constify seq_operations 2009-09-23 07:39:29 -07:00
page.c ksm: identify PageKsm pages 2009-09-22 07:17:31 -07:00
proc_devtree.c procfs: remove sparse errors in proc_devtree.c 2009-06-18 13:03:41 -07:00
proc_net.c
proc_sysctl.c
proc_tty.c
root.c
softirqs.c proc: export statistics for softirq to /proc 2009-06-18 13:03:41 -07:00
stat.c proc: export statistics for softirq to /proc 2009-06-18 13:03:41 -07:00
task_mmu.c procfs: provide stack information for threads 2009-09-23 07:39:41 -07:00
task_nommu.c mm_for_maps: shift down_read(mmap_sem) to the caller 2009-08-10 20:48:32 +10:00
uptime.c
version.c
vmcore.c proc: vmcore - use kzalloc in get_new_element() 2009-06-18 13:03:41 -07:00