From: Dave Chinner <david@fromorbit.com>
To: Daniel Phillips <daniel@phunq.net>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Subject: Re: [RFC][PATCH 2/2] tux3: Use writeback hook to remove duplicated core code
Date: Mon, 2 Jun 2014 13:30:47 +1000 [thread overview]
Message-ID: <20140602033047.GT14410@dastard> (raw)
In-Reply-To: <538B9E58.4000108@phunq.net>
On Sun, Jun 01, 2014 at 02:42:48PM -0700, Daniel Phillips wrote:
> Instead of re-implementing part of fs/fs-writeback.c, use a proposed
> net ->writeback super operation to drive delta writeback. For each
> inode that is cleaned, call inode_writeback_done(inode). For each
> inode that will be kept dirty in cache, call inode_writeback_touch
> so that the inode appears young to fs-writeback and does not trigger
> repeated ->writeback flushes.
>
> Signed-off-by: Daniel Phillips <daniel@tux3.org>
I have not looked at the sanity of the tux3 writeback algorithm, so
I'm not commenting on whether it works or not. However, this caught
my eye:
> static void __tux3_clear_dirty_inode(struct inode *inode, unsigned delta)
> {
> struct tux3_inode *tuxnode = tux_inode(inode);
> - tux3_inode_wb_lock(inode);
> spin_lock(&inode->i_lock);
> spin_lock(&tuxnode->lock);
> tux3_clear_dirty_inode_nolock(inode, delta, 0);
> spin_unlock(&tuxnode->lock);
> spin_unlock(&inode->i_lock);
> - tux3_inode_wb_unlock(inode);
> + inode_writeback_done(inode);
> }
I get very worried whenever I see locks inside inode->i_lock. In
general, i_lock is supposed to be the innermost lock that is taken,
and there are very few exceptions to that - the inode LRU list is
one of the few.
I don't know what the tuxnode->lock is, but I found this:
* inode->i_lock
* tuxnode->lock (to protect tuxnode data)
* tuxnode->dirty_inodes_lock (for i_ddc->dirty_inodes,
* Note: timestamp can be updated
* outside inode->i_mutex)
and this:
* inode->i_lock
* tuxnode->lock
* sb->dirty_inodes_lock
Which indicates that you take a filesystem global lock a couple of
layers underneath the VFS per-inode i_lock. I'd suggest you want to
separate the use of the vfs inode ilock from the locking heirarchy
of the tux3 inode....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2014-06-02 3:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-01 21:41 [RFC][PATCH 1/2] Add a super operation for writeback Daniel Phillips
2014-06-01 21:42 ` [RFC][PATCH 2/2] tux3: Use writeback hook to remove duplicated core code Daniel Phillips
2014-06-02 3:30 ` Dave Chinner [this message]
2014-06-02 20:07 ` Daniel Phillips
2014-06-02 3:15 ` [RFC][PATCH 1/2] Add a super operation for writeback Dave Chinner
2014-06-02 20:02 ` Daniel Phillips
2014-06-03 3:33 ` Dave Chinner
2014-06-03 7:01 ` Daniel Phillips
2014-06-03 7:26 ` Daniel Phillips
2014-06-03 7:47 ` OGAWA Hirofumi
2014-06-03 8:12 ` Dave Chinner
2014-06-03 8:57 ` OGAWA Hirofumi
2014-06-03 7:52 ` Dave Chinner
2014-06-03 14:05 ` Jan Kara
2014-06-03 14:14 ` Christoph Hellwig
2014-06-03 14:25 ` Theodore Ts'o
2014-06-03 15:21 ` Jan Kara
2014-06-03 22:37 ` Daniel Phillips
2014-06-04 20:16 ` Jan Kara
2014-06-02 8:30 ` Christian Stroetmann
2014-06-03 3:39 ` Dave Chinner
2014-06-03 5:30 ` Christian Stroetmann
2014-06-03 14:57 ` Theodore Ts'o
2014-06-03 16:30 ` Christian Stroetmann
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=20140602033047.GT14410@dastard \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=daniel@phunq.net \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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.