From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andrew Morton <akpm@zip.com.au>
Cc: mgross@unix-os.sc.intel.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
lse-tech@lists.sourceforge.net, richard.a.griffiths@intel.com,
ext2-devel@lists.sourceforge.net
Subject: Re: ext3 performance bottleneck as the number of spindles gets large
Date: Thu, 20 Jun 2002 10:54:49 +0100 [thread overview]
Message-ID: <20020620105449.A3824@redhat.com> (raw)
In-Reply-To: <3D1127D6.F6988C4B@zip.com.au>; from akpm@zip.com.au on Wed, Jun 19, 2002 at 05:54:46PM -0700
Hi,
On Wed, Jun 19, 2002 at 05:54:46PM -0700, Andrew Morton wrote:
> The vague plan there is to replace lock_kernel with lock_journal
> where appropriate. But ext3 scalability work of this nature
> will be targetted at the 2.5 kernel, most probably.
I think we can do better than that, with care. lock_journal could
easily become a read/write lock to protect the transaction state
machine, as there's really only one place --- the commit thread ---
where we end up changing the state of a transaction itself (eg. from
running to committing). For short-lived buffer transformations, we
already have the datalist spinlock.
There are a few intermediate types of operation, such as the
do_get_write_access. That's a buffer operation, but it relies on us
being able to allocate memory for the old version of the buffer if we
happen to be committing the bh to disk already. All of those cases
are already prepared to accept BKL being dropped during the memory
allocation, so there's no problem with doing the same for a short-term
buffer spinlock; and if the journal_lock is only taken shared in such
places, then there's no urgent need to drop that over the malloc.
Even the commit thread can probably avoid taking the journal lock in
many cases --- it would need it exclusively while changing a
transaction's global state, but while it's just manipulating blocks on
the committing transaction it can probably get away with much less
locking.
Cheers,
Stephen
next prev parent reply other threads:[~2002-06-20 9:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-19 21:29 ext3 performance bottleneck as the number of spindles gets large mgross
2002-06-20 0:54 ` Andrew Morton
2002-06-20 4:09 ` [Lse-tech] " Dave Hansen
2002-06-20 6:03 ` Andreas Dilger
2002-06-20 6:53 ` Andrew Morton
2002-06-20 9:54 ` Stephen C. Tweedie [this message]
2002-06-20 1:55 ` Andrew Morton
2002-06-20 6:05 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2002-06-20 15:26 ext3 performance bottleneck as the number of spindles gets la rge Griffiths, Richard A
2002-06-20 20:18 ` ext3 performance bottleneck as the number of spindles gets large Andrew Morton
2002-06-20 18:08 ` mgross
2002-06-20 21:25 ` Andrew Morton
2002-06-20 21:50 ext3 performance bottleneck as the number of spindles gets la rge Griffiths, Richard A
2002-06-21 7:58 ` ext3 performance bottleneck as the number of spindles gets large Andrew Morton
2002-06-21 18:46 ` mgross
2002-06-21 19:26 ` Chris Mason
2002-06-21 19:56 ` Andrew Morton
2002-06-23 4:02 ` Christopher E. Brown
2002-06-23 4:33 ` Andreas Dilger
2002-06-23 6:00 ` Christopher E. Brown
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=20020620105449.A3824@redhat.com \
--to=sct@redhat.com \
--cc=akpm@zip.com.au \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=mgross@unix-os.sc.intel.com \
--cc=richard.a.griffiths@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox