On Sat, Apr 17, 2010 at 12:51:09AM -0700, David Miller wrote: > 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? :-) May be yeah :) This could be also a tracing recursion somewhere. One good way to know is to put pause_graph_tracing() and unpause_graph_tracing() in the very beginning and end of the tracing paths. /me goes to try this. -- 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
