-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew James Wade wrote:
> I've modified stack.c to handle 4k stacks. It can also provide information
> for 8k stacks (fwiw) by changing STACK_GRANULARITY.
> 
> It found one stack with only 756 bytes left. I hope it's just due to a
> greedy boot-time function as I'm not running anything particularly exotic.
> (CIFS & Reiser4).

Yes, it does appear to be a boot-time function.  It eventually becomes
PID 1, and the stack usage shrinks considerably.

Here is a different approach that uses a kernel module, rather than
/dev/mem.  This module will display current stack usage for each PID, as
well as the maximum usage if the kernel has the stack-poison patch.
Also, the current call trace for each PID can be displayed if loaded
with "verbose=1".

for example:
1: init - free stack now: 3640, at max usage: 740
2: ksoftirqd/0 - free stack now: 3880, at max usage: 3788
3: watchdog/0 - free stack now: 3828, at max usage: 3736
4: events/0 - free stack now: 3784, at max usage: 3012
...

Disclaimer: This seems to work for me, but I'm not a very experienced
kernel hacker, so if it breaks, take care that you don't get hurt.

Comments and fixes are welcome.

Thanks,

Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDsa4iaI0dwg4A47wRAo14AKCbaraQkijBHpzSJdFzoTG1L/MXjgCg8VDe
130LL3/dMhRjVw4Wp8IN0a8=
=skKB
-----END PGP SIGNATURE-----