All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.