On Wed, Aug 29, 2007 at 6:34 PM, Eric Sandeen <sandeen@redhat.com> wrote:
quoted text
> Noticed today that the combination of 4KSTACKS and DEBUG_STACKOVERFLOW
> config options is a bit deadly.
>
> DEBUG_STACKOVERFLOW warns in do_IRQ if we're within THREAD_SIZE/8 of the
> end of useable stack space, or 512 bytes on a 4k stack.
>
> If we are, then it goes down the dump_stack path, which uses most, if
> not all, of the remaining stack, thereby turning a well-intentioned
> warning into a full-blown catastrophe.
>
> The callchain from the warning looks something like this, with stack
> usage shown as found on my x86 box:
>
> 4 dump_stack
> 4   show_trace
> 8     show_trace_log_lvl
> 4       dump_trace
>          print_context_stack
> 12          print_trace_address
>              print_symbol
> 232             __print_symbol
> 164               sprint_symbol
> 20                  printk
> ___
> 448
>
> 448 bytes to tell us that we're within 512 bytes (or less) of certain
> doom... and I think there's call overhead on top of that?
>
> The large stack usage in those 2 functions is due to big char arrays, of
> size KSYM_NAME_LEN (128 bytes) and KSYM_SYMBOL_LEN (223 bytes).
>
> IOW, the stack warning effectively reduces useful stack left in our itty
> bitty 4k stacks by over 10%.

Hi Eric,

Did you happen to get a patch together that reduces the stack usage of
dump_stack?

Also, what did you use to print your (above) indented callchain stack
usage of dump_stack?

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.

To do this safely it would seem to me that a leaner dump_stack() is needed...

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).

please advise, thanks.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/