From: David Miller <davem@xxxxxxxxxxxxx> Date: Fri, 16 Apr 2010 16:17:44 -0700 (PDT) > From: Frederic Weisbecker <fweisbec@xxxxxxxxx> > Date: Sat, 17 Apr 2010 01:14:12 +0200 > >> Hmm, just a random idea: do you think it could be due to stack overflows? >> Because the function graph eats more stack by digging to function graph >> handlers, ring buffer, etc... >> >> It diggs further than what is supposed to happen without tracing. > > I have mcount checking for stack-overflow by hand in assembler > during these tests, it even knows about the irq stacks. > > And those checks are not triggering. Ugh... hold on. They're not triggering because I put the test assembler into mcount and dynamic ftrace patches the call sites to bypass mcount altogether :-) Doing real tests now, and I bet you're right. That's pretty insane though, as we use 16K stacks on sparc64 and the gcc I'm using has the minimum stack frame decreased down to 176 bytes (used to be 192). I'd be interested to see what one of these too-large backtraces look like. Hmmm, will it be in the scheduler load balancing code? :-) Will report once I have some goot triggers. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
