xfs
[Top] [All Lists]

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

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

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