Re: xfs_iext_realloc_indirect and "XFS: possible memory allocation deadlock"

From: Dave Chinner <david@fromorbit.com>
To: Alex Lyakas <alex@zadarastorage.com>
Cc: Danny Shavit <danny@zadarastorage.com>,
	Shyam Kaushik <shyam@zadarastorage.com>,
	bfoster@redhat.com, Yair Hershko <yair@zadarastorage.com>,
	xfs@oss.sgi.com, Christoph Hellwig <hch@infradead.org>
Subject: Re: xfs_iext_realloc_indirect and "XFS: possible memory allocation deadlock"
Date: Thu, 7 Apr 2016 06:57:37 +1000	[thread overview]
Message-ID: <20160406205736.GB13574@dastard> (raw)
In-Reply-To: <A01B206564694781A7BE74415E4C6D1E@alyakaslap>

On Wed, Apr 06, 2016 at 07:39:21PM +0300, Alex Lyakas wrote:
> Hello Dave,
> 
> Thank you for your response. We understand your concerns and will do
> further testing with the vmalloc alternative.
> 
> Meanwhile, I found another issue happening when files have many
> extents. When unmounting XFS, we call
> xfs_inode_free => xfs_idestroy_fork => xfs_iext_destroy
> This goes over the whole indirection array and calls
> xfs_iext_irec_remove for each one of the erps (from the last one to
> the first one). As a result, we keep shrinking (reallocating
> actually) the indirection array until we shrink out all of its
> elements. When we have files with huge numbers of extents, umount
> takes 30-80 sec, depending on the amount of files that XFS loaded
> and the amount of indirection entries of each file. The unmount
> stack looks like [1].
> 
> That patch in [2] seems to address the issue. Do you think it is
> reasonable? It was tested only on kernel 3.18.19.

Looks like a good optimisation to make. Can you send it as proper
patch (separate thread) with this description and your signed-off-by
on it?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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