Messages in this thread | | | Date | Wed, 28 May 2008 10:13:51 -0500 | From | Eric Sandeen <> | Subject | Re: 4KSTACKS + DEBUG_STACKOVERFLOW harmful |
| |
Mike Snitzer wrote:
> Hi Eric, > > Did you happen to get a patch together that reduces the stack usage of > dump_stack?
Nope... but Andi Kleen sent a patch to put the warning on the irq stack rather than the main process stack, so it avoids the original problem with DEBUG_STACKOVERFLOW at least.
> Also, what did you use to print your (above) indented callchain stack > usage of dump_stack?
That was just hand-edited... :)
> I'd like to be able to audit the worst case stack usage of _all_ call > chains that originate from a given thread. This would effectively be > like DEBUG_STACK_USAGE except with finer grained (per call-chain) > statistics. One crude way of doing this is to dump_stack() whenever a > task's call-chain is the new "winner" as the biggest stack hog.
When will you test for the new winner?
> To do this safely it would seem to me that a leaner dump_stack() is needed...
It depends, I guess; if you have 8k stacks it'd probably fit ok in almost all cases, I think.
> Lastly, would it be reasonable to utilize systemtap to implement what > I described above? I'm actually looking to debug 4KSTACKS as > unobtrusively as possible so as to not alter the underlying kernel (in > this case it happens to be a RHEL5 kernel but this could apply to any > kernel).
I don't actually know if systemtap can do what you want (not saying it can't; just saying I don't know...)
-Eric
| |