From: Chris Mason <chris.mason@oracle.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Jeff Mahoney <jeffm@suse.com>,
ReiserFS Development List <reiserfs-devel@vger.kernel.org>,
Alexander Beregalov <a.beregalov@gmail.com>,
Alessio Igor Bogani <abogani@texware.it>,
Jonathan Corbet <corbet@lwn.net>,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 4/6] kill-the-BKL/reiserfs: release the write lock inside get_neighbors()
Date: Fri, 01 May 2009 09:29:03 -0400 [thread overview]
Message-ID: <1241184543.13084.13.camel@think.oraclecorp.com> (raw)
In-Reply-To: <20090501132506.GD6011@nowhere>
On Fri, 2009-05-01 at 15:25 +0200, Frederic Weisbecker wrote:
> On Fri, May 01, 2009 at 07:51:35AM +0200, Ingo Molnar wrote:
> >
> > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> >
> > > get_neighbors() is used to get the left and/or right blocks
> > > against a given one in order to balance a tree.
> > >
> > > sb_bread() is used to read the buffer of these neighors blocks and
> > > while it waits for this operation, it might sleep.
> > >
> > > The bkl was released at this point, and then we can also release
> > > the write lock before calling sb_bread().
> > >
> > > This is safe because if the filesystem is changed after this lock
> > > release, the function returns REPEAT_SEARCH (aka SCHEDULE_OCCURRED
> > > in the function header comments) in order to repeat the neighbhor
> > > research.
> > >
> > > [ Impact: release the reiserfs write lock when it is not needed ]
> >
> > This should also be safe because under the BKL we _already_ dropped
> > the lock when sb_bread() blocked (which it really would in the
> > normal case).
> >
> > There's one special case to consider though: sb_read() maps to
> > __bread() which can return without sleeping if the bh is already
> > uptodate. So if the filesystem _knows_ that the bh is already
> > uptodate and holds a reference to it (this is common pattern in
> > filesystems), it can have a locking assumption on that.
> >
sb_bread calls __bread which calls __getblk which always calls
might_sleep() before returning.
So, the unlock isn't adding a schedule that wasn't there before.
-chris
next prev parent reply other threads:[~2009-05-01 13:29 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-01 2:44 [PATCH 0/6] kill-the-BKL/reiserfs3: performance improvements, faster than Bkl based scheme Frederic Weisbecker
2009-05-01 2:44 ` [PATCH 1/6] kill-the-BKL/reiserfs: release write lock on fs_changed() Frederic Weisbecker
2009-05-01 6:31 ` Andi Kleen
2009-05-01 13:28 ` Frederic Weisbecker
2009-05-01 13:44 ` Chris Mason
2009-05-01 14:01 ` Frederic Weisbecker
2009-05-01 14:14 ` Chris Mason
2009-05-02 1:19 ` Frederic Weisbecker
2009-05-01 2:44 ` [PATCH 2/6] kill-the-BKL/reiserfs: release the write lock before rescheduling on do_journal_end() Frederic Weisbecker
2009-05-01 7:09 ` Ingo Molnar
2009-05-01 13:31 ` Frederic Weisbecker
2009-05-01 22:20 ` Frederic Weisbecker
2009-05-01 2:44 ` [PATCH 3/6] kill-the-BKL/reiserfs: release write lock while rescheduling on prepare_for_delete_or_cut() Frederic Weisbecker
2009-05-01 2:44 ` [PATCH 4/6] kill-the-BKL/reiserfs: release the write lock inside get_neighbors() Frederic Weisbecker
2009-05-01 5:51 ` Ingo Molnar
2009-05-01 13:25 ` Frederic Weisbecker
2009-05-01 13:29 ` Chris Mason [this message]
2009-05-01 13:31 ` Ingo Molnar
2009-05-01 2:44 ` [PATCH 5/6] kill-the-BKL/reiserfs: release the write lock inside reiserfs_read_bitmap_block() Frederic Weisbecker
2009-05-01 5:47 ` Ingo Molnar
2009-05-01 13:19 ` Frederic Weisbecker
2009-05-01 13:30 ` Chris Mason
2009-05-01 13:51 ` Frederic Weisbecker
2009-05-01 2:44 ` [PATCH 6/6] kill-the-BKL/reiserfs: release the write lock on flush_commit_list() Frederic Weisbecker
2009-05-01 5:42 ` Ingo Molnar
2009-05-01 13:13 ` Frederic Weisbecker
2009-05-01 13:23 ` Ingo Molnar
2009-05-01 13:26 ` Chris Mason
2009-05-01 13:29 ` Ingo Molnar
2009-05-01 13:54 ` Chris Mason
2009-05-01 5:35 ` [PATCH 0/6] kill-the-BKL/reiserfs3: performance improvements, faster than Bkl based scheme Ingo Molnar
2009-05-01 12:18 ` Thomas Meyer
2009-05-01 14:12 ` Frederic Weisbecker
2009-05-01 19:59 ` Linus Torvalds
2009-05-01 20:33 ` Ingo Molnar
2009-05-01 20:36 ` Ingo Molnar
2009-05-01 21:11 ` Linus Torvalds
2009-05-01 21:32 ` Ingo Molnar
2009-05-02 1:39 ` Frederic Weisbecker
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=1241184543.13084.13.camel@think.oraclecorp.com \
--to=chris.mason@oracle.com \
--cc=a.beregalov@gmail.com \
--cc=abogani@texware.it \
--cc=corbet@lwn.net \
--cc=fweisbec@gmail.com \
--cc=jeffm@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=reiserfs-devel@vger.kernel.org \
--cc=viro@zeniv.linux.org.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.