Detailed Stack Information Patch [2/3]

Stefani Seibold

author

2009-03-31 14:52 UTC #0 lore raw

fs/proc/Makefile +1 -0

diff -u -N -r linux-2.6.29.orig/fs/proc/Makefile linux-2.6.29/fs/proc/Makefile
@@ -25,3 +25,4 @@
 proc-$(CONFIG_PROC_DEVICETREE)	+= proc_devtree.o
 proc-$(CONFIG_PRINTK)	+= kmsg.o
 proc-$(CONFIG_PROC_PAGE_MONITOR)	+= page.o
+proc-$(CONFIG_PROC_STACK_MONITOR) += stackmon.o

fs/proc/stackmon.c +254 -0

254 lines not on this page · raw message

init/Kconfig +10 -0

diff -u -N -r linux-2.6.29.orig/init/Kconfig linux-2.6.29/init/Kconfig
@@ -964,6 +964,16 @@
 	  Disabling these interfaces will reduce the size of the kernel by
 	  approximately 1kb.
 
+config PROC_STACK_MONITOR
+ 	default y
+	depends on PROC_STACK
+	bool "Enable /proc/stackmon detailed stack monitoring"
+ 	help
+	  This enables detailed monitoring of process and thread stack
+	  utilization via the /proc/stackmon interface.
+	  Disabling these interfaces will reduce the size of the kernel by
+	  approximately 2kb.
+
 endmenu		# General setup
 
 config HAVE_GENERIC_DMA_COHERENT

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Ingo Molnar

2009-04-01 19:36 UTC #1 lore raw

init/Kconfig line 975

Quoted 9 lines · Stefani Seibold

init/Kconfig +9 -0

+config PROC_STACK_MONITOR
+ 	default y
+	depends on PROC_STACK
+	bool "Enable /proc/stackmon detailed stack monitoring"
+ 	help
+	  This enables detailed monitoring of process and thread stack
+	  utilization via the /proc/stackmon interface.
+	  Disabling these interfaces will reduce the size of the kernel by
+	  approximately 2kb.

Hm, i'm not convinced about this one. Stupid question: what's wrong with ulimit -s?

Also, if for some reason you dont want to (or cannot) enforce a system-wide stack size ulimit, or it has some limitation that makes it impractical for you - if we add what i suggested to the /proc/*/maps files, your user-space watchdog daemon could scan those periodically and report any excesses and zap the culprit ... right?

Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Stefani Seibold

author

2009-04-02 21:20 UTC #2 lore raw

Am Mittwoch, den 01.04.2009, 21:36 +0200 schrieb Ingo Molnar:

Quoted 15 lines · Stefani Seibold

init/Kconfig line 975

Quoted 10 lines

init/Kconfig +9 -0

+config PROC_STACK_MONITOR
+ 	default y
+	depends on PROC_STACK
+	bool "Enable /proc/stackmon detailed stack monitoring"
+ 	help
+	  This enables detailed monitoring of process and thread stack
+	  utilization via the /proc/stackmon interface.
+	  Disabling these interfaces will reduce the size of the kernel by
+	  approximately 2kb.

Hm, i'm not convinced about this one. Stupid question: what's wrong with ulimit -s?

To tell a long story short, you are right. After a quick investigation of the glibc 2.9 library i figure out that this is also the default stack size of a thread started with pthread_create().

Quoted 5 lines

Also, if for some reason you dont want to (or cannot) enforce a system-wide stack size ulimit, or it has some limitation that makes it impractical for you - if we add what i suggested to the /proc/*/maps files, your user-space watchdog daemon could scan those periodically and report any excesses and zap the culprit ... right?

I think a user space daemon will be the a good way if the /proc/*/maps or /proc/*/stack will provide the following information:

- start address of the stack
- current address of the stack pointer
- highest used address in the stack

Quoted 2 lines

Ingo

Stefani

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Mikael Pettersson

2009-04-03 07:32 UTC #3 lore raw

Quoted 6 lines · Stefani Seibold

I think a user space daemon will be the a good way if the /proc/*/maps or /proc/*/stack will provide the following information:
- start address of the stack
- current address of the stack pointer
- highest used address in the stack

You're assuming
1. a thread has exactly one stack
2. the stack is a single unbroken area
3. the kernel knows the location of this area

None of these assumptions are necessarily valid, esp. in the presence of virtualizers, managed runtimes, or mixed interpreted/JIT language implementations.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Stefani Seibold

author

2009-04-03 07:55 UTC #4 lore raw

Am Freitag, den 03.04.2009, 09:32 +0200 schrieb Mikael Pettersson:

Quoted 8 lines

Quoted 6 lines · Stefani Seibold
I think a user space daemon will be the a good way if the /proc/*/maps or /proc/*/stack will provide the following information:
- start address of the stack
- current address of the stack pointer
- highest used address in the stack

Quoted 8 lines

You're assuming
1. a thread has exactly one stack
2. the stack is a single unbroken area
3. the kernel knows the location of this area
None of these assumptions are necessarily valid, esp. in the presence of virtualizers, managed runtimes, or mixed interpreted/JIT language implementations.

We are talking about the kernel view. And from this point a thread has only one stack and it is a single mapped continuous area. There are only one exception and that is the sigaltstack().

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Mikael Pettersson

2009-04-03 08:53 UTC #5 lore raw

Quoted 14 lines · Stefani Seibold

Am Freitag, den 03.04.2009, 09:32 +0200 schrieb Mikael Pettersson:
Quoted 13 lines
Quoted 6 lines · Stefani Seibold
I think a user space daemon will be the a good way if the /proc/*/maps or /proc/*/stack will provide the following information:
- start address of the stack
- current address of the stack pointer
- highest used address in the stack
You're assuming
1. a thread has exactly one stack
2. the stack is a single unbroken area
3. the kernel knows the location of this area

Quoted 7 lines

Quoted 3 lines
None of these assumptions are necessarily valid, esp. in the presence of virtualizers, managed runtimes, or mixed interpreted/JIT language implementations.
We are talking about the kernel view. And from this point a thread has only one stack and it is a single mapped continuous area. There are only one exception and that is the sigaltstack().

So you're proposing to have the kernel export data which, while accurate from the kernel's limited view, may be arbitrarily inaccurate for the user-space process in question?

Also I'm not sure you even need a kernel extension for the optimistic case of a single simple stack. ptrace to get stack pointer then scan /proc/$tid/maps to identify the corresponding mapping should give the same information, no?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>