From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 7/7] XFS: don't use vnodes where unnecessary
Date: Mon, 18 Aug 2008 10:42:09 +1000 [thread overview]
Message-ID: <20080818004209.GH19760@disturbed> (raw)
In-Reply-To: <20080814201022.GA20557@infradead.org>
On Thu, Aug 14, 2008 at 04:10:22PM -0400, Christoph Hellwig wrote:
> > do {
> > + struct inode *inode;
> > + boolean_t vnode_refed;
> > + xfs_inode_t *ip = NULL;
>
> This should not be inode_refed, no? :)
Yeah ;)
> > - vp = VFS_I(ip);
> > - if (!vp) {
> > + if (xfs_iflags_test(ip, (XFS_IRECLAIM|XFS_IRECLAIMABLE))) {
>
> These changes really need to be folded into the previous patch for
> bisectability reasons..
Right - this was catching all this bits that I missed in the
previous patch ;)
>
> > + inode = VFS_I(ip);
> > + if (VN_BAD(inode)) {
>
> Just use is_bad_inode directly. (Also in a few other places)
Will do.
> > } else {
> > - /* safe to unlock here as we have a reference */
> > + if (!xfs_ilock_nowait(ip, lock_flags)) {
> > + /* leave it to reclaim */
> > + read_unlock(&pag->pag_ici_lock);
> > + continue;
> > + }
> > read_unlock(&pag->pag_ici_lock);
> > }
>
> Maybe not for this patch, but in general, why do we even bother about
> the inodes we can't get a reference to, shouldn't we just always leave
> this to reclaim?
Right now, we either get a reference or an ilock to prevent reclaim
from freeing it. The case ofthe vnode disappearing made it difficult
to make a clear delineation. With the combined inode, it is much
easier to make this distinction, but if we are doing ascending order
writeback of inodes, we really want to get all the inodes that are
dirty regardless of whether they are in reclaim or not.
> > - if ((flags & SYNC_DELWRI) && VN_DIRTY(vp)) {
> > + if ((flags & SYNC_DELWRI) && VN_DIRTY(VFS_I(ip))) {
>
> Why not use the "inode" variable we have in scope anyway?
Yup, should do that.
> > + if (!(inode->i_state & I_CLEAR))
> > + return atomic_read(&inode->i_count);
>
> Well, it's just zero when the inode is out of the vfs, so we could
> probably simply do it unconditional.
Ok, I'll have a look at that.
>
> > + vp = vn_grab(VFS_I(ip));
> > + if (vp) {
>
> Please switch this one to igrab, and the inode name, too. As this
> is the last caller of vn_grab we can kill it now.
Ok, I'll fix that one up, too.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2008-08-18 0:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1218698083-11226-1-git-send-email-david@fromorbit.com>
[not found] ` <1218698083-11226-6-git-send-email-david@fromorbit.com>
[not found] ` <20080814190001.GA19070@infradead.org>
2008-08-18 0:19 ` [PATCH 5/7] XFS: Make use of the init-once slab optimisation Dave Chinner
[not found] ` <1218698083-11226-5-git-send-email-david@fromorbit.com>
[not found] ` <20080814194702.GB12237@infradead.org>
2008-08-18 0:19 ` [PATCH 4/7] XFS: Never call mark_inode_dirty_sync() directly Dave Chinner
[not found] ` <1218698083-11226-7-git-send-email-david@fromorbit.com>
[not found] ` <20080814200006.GC12237@infradead.org>
2008-08-18 0:34 ` [PATCH 6/7] XFS: Combine the XFS and Linux inodes Dave Chinner
[not found] ` <1218698083-11226-8-git-send-email-david@fromorbit.com>
[not found] ` <20080814201022.GA20557@infradead.org>
2008-08-18 0:42 ` Dave Chinner [this message]
[not found] ` <20080814194550.GA12237@infradead.org>
2008-08-18 1:13 ` [PATCH 0/7] RFC: combine linux and XFS inodes Dave Chinner
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=20080818004209.GH19760@disturbed \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.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