Re: stack overflow on Sparc64

[Mikulas Patocka]

On Tue, 17 Jun 2008, David Miller wrote:

> From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
> Date: Tue, 17 Jun 2008 20:47:57 -0400 (EDT)
>
> > Wait queue waking looks like being written by a high-level maniac --- it
> > contains 8 levels of calls (none of them inlined). 7 of these calls (until
> > try_to_wake_up) do nothing but pass arguments to lower level call. And
> > each of these calls allocate at least 192 bytes of stack space. All these
> > 7 useless calls consume 1360 bytes of stack (and cause windows traps that
> > needlessly damage performance). Would you agree to inline most of the
> > calls to save stack? Or do you see another solution?
>
> Some of them could be inlined but there are a few limiting
> factors here.

I inlined three of them, I think I can inline another two. So hopefully, 
I'll be able to shring 8-call depth to 3-call depth.

> Even spin lock acquisitions are function calls, limiting how
> much leaf function and tail call optimizations can be done.

Tail call optimization is not done at all if you compile kernel with stack 
checking. This contributes to the stack overflow too.

> Also, wake_up_bit has this aggregate local variable "key" whose
> address is passed down to subsequent functions, which limits
> optimizations even further.
>
> It could still be improved a lot, however.
>
> But the level of recursion possible by the current device layer is
> excessive and needs to be curtained irrespective of these generic
> wakeup and sparc64 interrupt stack issues.

I fixed that too.

BTW. what's the purpose of having 192-byte stack frame? There are 16 
8-byte registers being saved per function call, so 128-byte frame should 
be sufficient, shoudn't? The ABI specifies that some additional entries 
must be present even if unused, but I don't see reason for them. Would 
something bad happen if GCC started to generate 128-byte stacks?

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