All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valerie Henson <val_henson@linux.intel.com>
To: Dave Kleikamp <shaggy@austin.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	ext4 development <linux-ext4@vger.kernel.org>,
	Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH] EXT2: Remove superblock lock contention in ext2_statfs
Date: Mon, 25 Sep 2006 09:46:39 -0700	[thread overview]
Message-ID: <20060925164637.GA30477@goober> (raw)
In-Reply-To: <1158622685.11940.52.camel@kleikamp.austin.ibm.com>

On Mon, Sep 18, 2006 at 06:38:05PM -0500, Dave Kleikamp wrote:
> On Mon, 2006-09-18 at 15:36 -0500, Dave Kleikamp wrote:
> > EXT2: Remove superblock lock contention in ext2_statfs
> > 
> > Fix a performance degradation introduced in 2.6.17.  (30% degradation running
> > dbench with 16 threads)
> > 
> > Patch 21730eed11de42f22afcbd43f450a1872a0b5ea1, which claims to make
> > EXT2_DEBUG work again, moves the taking of the kernel lock out of debug-only
> > code in ext2_count_free_inodes and ext2_count_free_blocks and into
> > ext2_statfs.  This patch reverses that part of the patch.
> > 
> > Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>
> 
> Eric Sandeen pointed out to me that taking the superblock lock in
> ext2_count_free_* will cause a deadlock when EXT2FS_DEBUG is enabled,
> since the superblock is locked in write_super().
> 
> We found that the same problem was fixed in ext3 with this patch
> (forgive the long link):
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5b11687924e40790deb0d5f959247ade82196665;hp=2384f55f8aa520172c995965bd2f8a9740d53095
> 
> The patch below just removes the use of the superblock lock in the debug
> code.

(Sorry for the delay; been on vacation.)

Heh, I ran into the same lock nesting issues as you when I first tried
to fix this; the lock debugging code found it for me.  I asked for
feedback on the locking issue when I submitted the patch, but no one
had any opinions then, so I chose consistency over possible
contention.  Al Viro snorted at the idea of consistency in the results
of statfs (I paraphrase his IRC remarks), and thinking about it
further, I realized the debug code should not be doing these checks in
statfs anyway; only on mount and unmount.  This is because it appears
that the block group accounting and the overall fs accounting are done
non-atomically - see group_reserve_blocks() for example - and part of
what the code does is reconcile these two numbers.  It is legal for a
valid fs to have the block group summaries and the fs-wide summaries
out of sync, so the debug code could erroneously report an error,
leading some poor soul on a wild goose chase.  Removing this code from
statfs also happens to fix the locking issues nicely.

Rewriting this has been on my todo list for about 6 months now -
anyone interested in grabbing it?  I'm on #linuxfs on irc.oftc.net if
anyone wants to chat about it.

-VAL

      reply	other threads:[~2006-09-25 16:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-18 20:36 [PATCH] EXT2: Remove superblock lock contention in ext2_statfs Dave Kleikamp
2006-09-18 23:38 ` Dave Kleikamp
2006-09-25 16:46   ` Valerie Henson [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=20060925164637.GA30477@goober \
    --to=val_henson@linux.intel.com \
    --cc=akpm@osdl.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaggy@austin.ibm.com \
    --cc=tytso@mit.edu \
    /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.