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

[Dave Chinner <david@fromorbit.com>]

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...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs