All of lore.kernel.org
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: Eric Sandeen <sandeen@redhat.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 0/8] Clean up ext4's block free code paths
Date: Mon, 23 Nov 2009 09:46:29 -0500	[thread overview]
Message-ID: <20091123144629.GF2532@thunk.org> (raw)
In-Reply-To: <4B0A072C.5000305@redhat.com>

On Sun, Nov 22, 2009 at 09:53:16PM -0600, Eric Sandeen wrote:
> 
> Have you double-checked stack usage before & after the series, just
> in case all the folding-in increased some stack footprints?

The static stack footprints (on an x86) showed slight increases:

Before:
ext4_mb_free_blocks [vmlinux]:		124
ext4_ext_truncate [vmlinux]:		100

After applying the patch series:

ext4_free_blocks [vmlinux]:		136
ext4_ext_truncate [vmlinux]:		116

I was more concerned about the dynamic stack usage, so I ran xfstests
QA and then re-running test #74 (fstest), which seems to be the one
that uses the most stack.  The results are not fully consistent (which
is why I manually re-ran #74 a few times to try to provoke the
smallest possible stack space left), but the worse case stack usage I
was able to find was:

Before:

fstest used greatest stack depth: 1084 bytes left

After applying the patch series:

fstest used greatest stack depth: 1024 bytes left

So it's slightly worse, but hopefully not enough to push us over the
edge.  I think I can move some stack variables into inner blocks in
ext4_free_blocks() which should help, if we think this is a major
problem.

              	      	  	      	       - Ted

      reply	other threads:[~2009-11-23 14:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-23  2:18 [PATCH 0/8] Clean up ext4's block free code paths Theodore Ts'o
2009-11-23  2:18 ` [PATCH 1/8] ext4: move ext4_forget() to ext4_jbd2.c Theodore Ts'o
2009-11-23  2:18 ` [PATCH 2/8] ext4: fold ext4_journal_revoke() into ext4_forget() Theodore Ts'o
2009-11-23  2:18 ` [PATCH 3/8] ext4: fold ext4_journal_forget() " Theodore Ts'o
2009-11-23  2:18 ` [PATCH 4/8] ext4: fold ext4_free_blocks() and ext4_mb_free_blocks() Theodore Ts'o
2009-11-23  2:18 ` [PATCH 5/8] ext4: call ext4_forget() from ext4_free_blocks() Theodore Ts'o
2009-11-23 19:22   ` Andreas Dilger
2009-11-23 20:28     ` tytso
2009-11-23  2:18 ` [PATCH 6/8] ext4: print i_mode in octal in ext4 tracepoints Theodore Ts'o
2009-11-23  2:18 ` [PATCH 7/8] ext4: add check for wraparound in ext4_data_block_valid() Theodore Ts'o
2009-11-23  2:18 ` [PATCH 8/8] ext4: use ext4_data_block_valid() in ext4_free_blocks() Theodore Ts'o
2009-11-23  3:53 ` [PATCH 0/8] Clean up ext4's block free code paths Eric Sandeen
2009-11-23 14:46   ` tytso [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=20091123144629.GF2532@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /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.