From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: "Michael L. Semon" <mlsemon35@gmail.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: Multi-CPU harmless lockdep on x86 while copying data
Date: Mon, 10 Mar 2014 04:12:53 -0700 [thread overview]
Message-ID: <20140310111253.GA4801@infradead.org> (raw)
In-Reply-To: <20140310103716.GA1431@infradead.org>
On Mon, Mar 10, 2014 at 03:37:16AM -0700, Christoph Hellwig wrote:
> I think the right fix is to stop abusing the iolock in filestreams.
> To me it seems like a look inside fstrm_item_t should be fine
> for what the filestreams code wants if I understand it correctly.
Seems like the iolock could be removed fairly easily by using either of
the two options:
a) reference count fstrm_item, and just grab a reference to it for each
child as well as the parent and insert it multiple times. Kill
->pip.
b) only allocate and insert fstrm_items for directories. Find the
directory by grabbing an entry off inode->i_dentry and then grabbing
the parent. There always should be a dentry around when we allocate
blocks, and if none we can just skip out of the filestreams
allocator if there's none. For the cases that matter there is.
Both mean that the race it tries to protect against using the iolock is
remove entirely, and the code becomes more efficient as well. Option a)
seems simple to implement, but b) will save a lot more memory and
operations when using the filestreams allocator.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-03-10 11:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-09 2:58 Multi-CPU harmless lockdep on x86 while copying data Michael L. Semon
2014-03-10 2:55 ` Dave Chinner
2014-03-10 10:37 ` Christoph Hellwig
2014-03-10 11:12 ` Christoph Hellwig [this message]
2014-03-10 20:51 ` Dave Chinner
2014-03-11 16:48 ` Christoph Hellwig
2014-03-10 20:46 ` Dave Chinner
2014-03-10 21:16 ` Ben Myers
2014-03-10 21:24 ` Dave Chinner
2014-03-10 22:10 ` Ben Myers
2014-03-10 20:52 ` Ben Myers
2014-03-10 21:20 ` Dave Chinner
2014-03-10 21:30 ` Ben Myers
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=20140310111253.GA4801@infradead.org \
--to=hch@infradead.org \
--cc=david@fromorbit.com \
--cc=mlsemon35@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).