All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Jeff Mahoney <jeffm@suse.com>,
	ReiserFS Development List <reiserfs-devel@vger.kernel.org>,
	Chris Mason <chris.mason@oracle.com>,
	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, 1 May 2009 15:25:07 +0200	[thread overview]
Message-ID: <20090501132506.GD6011@nowhere> (raw)
In-Reply-To: <20090501055135.GF5983@elte.hu>

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.
> 
> No such assumption seems to be present here though.
> 
> 	Ingo


Yeah, fortunately it doesn't base its check on the state of the
buffer but on the tree number of rebalancing.

But I have to remember this pattern, it could be present elsewhere
in reiserfs.

Thanks.


  reply	other threads:[~2009-05-01 13:25 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 [this message]
2009-05-01 13:29       ` Chris Mason
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=20090501132506.GD6011@nowhere \
    --to=fweisbec@gmail.com \
    --cc=a.beregalov@gmail.com \
    --cc=abogani@texware.it \
    --cc=chris.mason@oracle.com \
    --cc=corbet@lwn.net \
    --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.