xfs
[Top] [All Lists]

Re: Large Stack Usage in One More Function

To: Steve Lord <lord@xxxxxxx>
Subject: Re: Large Stack Usage in One More Function
From: Andi Kleen <ak@xxxxxxx>
Date: Tue, 27 Aug 2002 19:27:04 +0200
Cc: Danny Cox <danscox@xxxxxxxxxxxxxx>, XFS Mailing List <linux-xfs@xxxxxxxxxxx>
In-reply-to: <1030467882.16697.28.camel@jen.americas.sgi.com>; from lord@sgi.com on Tue, Aug 27, 2002 at 12:04:42PM -0500
References: <1030467482.1611.14.camel@wiley> <1030467882.16697.28.camel@jen.americas.sgi.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Tue, Aug 27, 2002 at 12:04:42PM -0500, Steve Lord wrote:
> 
> On Tue, 2002-08-27 at 11:58, Danny Cox wrote:
> > 
> > Hi, Guys!
> > 
> >     After having read of the stack "issues" awhile back, and then having an
> > idea or two gel in my head (it didn't hurt much ;-), I put them
> > together, and found that xfs_ioctl() is using 752 bytes of stack.  I
> > chose 512 as the number of bytes above which to complain about, and
> > looking at the code, I'd guess that the var "vattr_t va" struct is the
> > main culprit.
> 
> Probably not just the vattr_t, most of the function is a large switch
> statement, and each case in there has its own on the stack variables.
> If the compiler is not being smart about it they would each get
> their own non-overlapping space.
gcc isn't very smart in that unfortunately. All local variables no matter if in 
a subscope 
or not or being dead for most of the function or not contribute the stack frame.
The only way to get a separate stack frame is to either use alloca() or a 
different
function.

-Andi


<Prev in Thread] Current Thread [Next in Thread>