public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Function stack size usage (was [PATCH][1/2] SquashFS)
Date: Sun, 20 Mar 2005 16:59:02 -0800	[thread overview]
Message-ID: <20050320165902.10d99417.akpm@osdl.org> (raw)
In-Reply-To: <423E032C.4020103@lougher.demon.co.uk>

Phillip Lougher <phillip@lougher.demon.co.uk> wrote:
>
> Andrew Morton wrote:
> > Phillip Lougher <phillip@lougher.demon.co.uk> wrote:
> >>
> >>+static struct inode *squashfs_iget(struct super_block *s, squashfs_inode inode)
> >>+{
> >>+	struct inode *i;
> >>+	squashfs_sb_info *msBlk = (squashfs_sb_info *)s->s_fs_info;
> >>+	squashfs_super_block *sBlk = &msBlk->sBlk;
> >>+	unsigned int block = SQUASHFS_INODE_BLK(inode) +
> >>+		sBlk->inode_table_start;
> >>+	unsigned int offset = SQUASHFS_INODE_OFFSET(inode);
> >>+	unsigned int ino = SQUASHFS_MK_VFS_INODE(block
> >>+		- sBlk->inode_table_start, offset);
> >>+	unsigned int next_block, next_offset;
> >>+	squashfs_base_inode_header inodeb;
> > 
> > 
> > How much stack space is being used here?  Perhaps you should run
> > scripts/checkstack.pl across the whole thing.
> > 
> 
> A lot of the functions use a fair amount of stack (I never thought it 
> was excessive)...  This is the result of running checkstack.pl against 
> the code on Intel.
> 
> 0x00003a3c get_dir_index_using_name:                    596
> 0x00000d80 squashfs_iget:                               488
> 0x000044d8 squashfs_lookup:                             380
> 0x00003d00 squashfs_readdir:                            372
> 0x000020fe squashfs_fill_super:                         316
> 0x000031b8 squashfs_readpage:                           308
> 0x00002f5c read_blocklist:                              296
> 0x00003634 squashfs_readpage4K:                         284
> 
> A couple of these functions show a fair amount of stack use.  What is 
> the maximum acceptable usage,

There's no hard-and-fast rule.  The conditions running up to a stack
overrun are necessarily complex, and rare.  But you can see that for a
twenty or thirty function deep call stack, 500 bytes is a big bite out of
4k.

> i.e. do any of the above functions need 
> work to reduce their stack usage?

I'd say so, yes.  If at all possible.

      reply	other threads:[~2005-03-21  0:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-14 16:24 [PATCH][1/2] SquashFS Phillip Lougher
2005-03-15  0:38 ` Matt Mackall
2005-03-15  1:47   ` Nick Piggin
2005-03-15  2:33     ` Matt Mackall
2005-03-15  8:47     ` Paul Jackson
2005-03-15 15:50       ` Phillip Lougher
2005-03-15 17:27         ` Matt Mackall
2005-03-15 16:19           ` Phillip Lougher
2005-03-15 19:06             ` Paul Jackson
2005-03-16  1:50               ` Junio C Hamano
2005-03-16  7:14                 ` Paul Jackson
2005-03-17 20:06                 ` jerome lacoste
2005-03-15  0:51 ` Andrew Morton
2005-03-19  1:56   ` Kmap_atomic vs Kmap Phillip Lougher
2005-03-19  3:41     ` Andrew Morton
2005-03-20 23:11   ` Function stack size usage (was [PATCH][1/2] SquashFS) Phillip Lougher
2005-03-21  0:59     ` Andrew Morton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050320165902.10d99417.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillip@lougher.demon.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox