From: Christoph Hellwig <hch@infradead.org>
To: xfs@oss.sgi.com
Subject: Re: [PATCH 0/9] stop taking the iolock in the reclaim path
Date: Tue, 25 Aug 2009 14:41:30 -0400 [thread overview]
Message-ID: <20090825184130.GA17708@infradead.org> (raw)
In-Reply-To: <20090825182134.299870049@bombadil.infradead.org>
Ah sorry, I resent the old lockdep patches, Will send the real one
ASAP.
On Tue, Aug 25, 2009 at 02:21:34PM -0400, Christoph Hellwig wrote:
> Currently we take the iolock in the reclaim path in various places.
> Taking it in the inode reclaim path means however that we can't take
> it while doing memory allocations that recurse back into the filesystem,
> and recently lockdep has been enhanced to find these cases and noticed
> quite a few of these in XFS.
>
> We had similar issues with the ilock, but we could get away with just
> stopping to do filesystem-recursing allocation under the ilock as there
> were just a few. The iolock is however taken over larger critical sections
> protection actual I/O and it's almost impossible to switch all these to
> NOFS allocations. Based on what the iolock is used for we don't actually
> need it in the reclaim path, though - at this point the inode is dead
> and no one has any other reference to it. See the listing in the
> first patch for a more detailed list of our current iolock holders and
> why they can't contend with the reclaim path.
>
> I would greatly appreciate some indepth-review of this to make sure I
> haven't missed a big loophole..
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
---end quoted text---
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2009-08-25 18:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-25 18:21 [PATCH 0/9] stop taking the iolock in the reclaim path Christoph Hellwig
2009-08-25 18:21 ` [PATCH 1/9] xfs: avoid memory allocation under m_peraglock in growfs code Christoph Hellwig
2009-08-25 18:21 ` [PATCH 2/9] xfs: switch to NOFS allocation under i_lock in xfs_getbmap Christoph Hellwig
2009-08-25 18:21 ` [PATCH 3/9] xfs: switch to NOFS allocation under i_lock in xfs_da_state_alloc Christoph Hellwig
2009-08-25 18:21 ` [PATCH 4/9] xfs: switch to NOFS allocation under i_lock in xfs_da_buf_make Christoph Hellwig
2009-08-25 18:21 ` [PATCH 5/9] xfs: switch to NOFS allocation under i_lock in xfs_dir_cilookup_result Christoph Hellwig
2009-08-25 18:21 ` [PATCH 6/9] xfs: switch to NOFS allocation under i_lock in xfs_buf_associate_memory Christoph Hellwig
2009-08-25 18:21 ` [PATCH 7/9] xfs: switch to NOFS allocation under i_lock in xfs_attr_rmtval_set Christoph Hellwig
2009-08-25 18:21 ` [PATCH 8/9] xfs: switch to NOFS allocation under i_lock in xfs_readlink_bmap Christoph Hellwig
2009-08-25 18:21 ` [PATCH 9/9] xfs: switch to NOFS allocation under i_lock in xfs_attr_rmtval_get Christoph Hellwig
2009-08-25 18:41 ` Christoph Hellwig [this message]
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=20090825184130.GA17708@infradead.org \
--to=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