[Top] [All Lists]

Re: Multi-CPU harmless lockdep on x86 while copying data

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: Multi-CPU harmless lockdep on x86 while copying data
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 11 Mar 2014 07:51:18 +1100
Cc: "Michael L. Semon" <mlsemon35@xxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140310111253.GA4801@xxxxxxxxxxxxx>
References: <531BD8B9.1090400@xxxxxxxxx> <20140310025523.GV6851@dastard> <20140310103716.GA1431@xxxxxxxxxxxxx> <20140310111253.GA4801@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Mar 10, 2014 at 04:12:53AM -0700, Christoph Hellwig wrote:
> 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.

Yeah, b) seems like the way to simplify it - the filestreams code
really only needs to track the parent/ag relationship rather than
the child/parent relationship if there is a reliable way of
determining the parent from the child.

What do we do with hardlinked files in this case? I'm happy to say
"too bad" for these files mainly because the filestream allocator is
aimed at associating multiple file creations together, so hard links
really don't matter AFAICT...


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>