From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, Ted Tso <tytso@mit.edu>,
Martijn Coenen <maco@android.com>,
tj@kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/3] writeback: Avoid skipping inode writeback
Date: Wed, 10 Jun 2020 17:30:56 +0200 [thread overview]
Message-ID: <20200610153056.GA20677@quack2.suse.cz> (raw)
In-Reply-To: <20200610150203.GA21733@infradead.org>
On Wed 10-06-20 08:02:03, Christoph Hellwig wrote:
> This generall looks ok, but a few nitpicks below:
>
> > -static void redirty_tail(struct inode *inode, struct bdi_writeback *wb)
> > +static void __redirty_tail(struct inode *inode, struct bdi_writeback *wb)
>
> I think redirty_tail_locked would be a more decriptive name, and also
> fit other uses in this file (e.g. inode_io_list_move_locked and
> inode_io_list_del_locked).
Fair enough, will do.
> > {
> > + assert_spin_locked(&inode->i_lock);
> > if (!list_empty(&wb->b_dirty)) {
>
> Nit: I find an empty line after asserts and before the real code starts
> nice on the eye.
Sure.
> > break;
> > list_move(&inode->i_io_list, &tmp);
> > moved++;
> > + spin_lock(&inode->i_lock);
> > if (flags & EXPIRE_DIRTY_ATIME)
> > - set_bit(__I_DIRTY_TIME_EXPIRED, &inode->i_state);
> > + inode->i_state |= I_DIRTY_TIME_EXPIRED;
> > + inode->i_state |= I_SYNC_QUEUED;
> > + spin_unlock(&inode->i_lock);
>
> I wonder if the locking changes should go into a prep patch vs the
> actual logic changes related to I_SYNC_QUEUED? That would untangle
> the patch quite a bit and make it easier to follow.
OK, will do.
> > #define I_WB_SWITCH (1 << 13)
> > #define I_OVL_INUSE (1 << 14)
> > #define I_CREATING (1 << 15)
> > +#define I_SYNC_QUEUED (1 << 16)
>
> FYI, this conflicts with the I_DONTCAT addition in mainline now.
Yup, I've already found out when rebasing...
Thanks for review!
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2020-06-10 15:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 9:18 [PATCH 0/3] writeback: Lazytime handling fix and cleanups Jan Kara
2020-06-01 9:18 ` [PATCH 1/3] writeback: Avoid skipping inode writeback Jan Kara
2020-06-05 14:11 ` Sasha Levin
2020-06-10 15:02 ` Christoph Hellwig
2020-06-10 15:30 ` Jan Kara [this message]
2020-06-01 9:18 ` [PATCH 2/3] writeback: Fix sync livelock due to b_dirty_time processing Jan Kara
2020-06-10 15:06 ` Christoph Hellwig
2020-06-10 15:54 ` Jan Kara
2020-06-10 15:58 ` Christoph Hellwig
2020-06-01 9:18 ` [PATCH 3/3] writeback: Drop I_DIRTY_TIME_EXPIRE Jan Kara
2020-06-10 15:11 ` Christoph Hellwig
2020-06-10 16:20 ` Jan Kara
2020-06-10 10:04 ` [PATCH 0/3] writeback: Lazytime handling fix and cleanups Jan Kara
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=20200610153056.GA20677@quack2.suse.cz \
--to=jack@suse.cz \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=maco@android.com \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
--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.