Messages in this thread | | | Date | Wed, 28 May 2008 10:36:07 -0400 | From | "Mike Snitzer" <> | Subject | Re: 4KSTACKS + DEBUG_STACKOVERFLOW harmful |
| |
On Wed, Aug 29, 2007 at 6:34 PM, Eric Sandeen <sandeen@redhat.com> wrote: > 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.
| |