xfs_iext_realloc_indirect and "XFS: possible memory allocation deadlock"

[Alex Lyakas]

Hello Dave, Brian, Christoph,

We are still encountering cases, in which different IO patterns beat XFS 
preallocation schemes, resuling in highly fragmented files, having 100s of 
thousands and sometimes millions of extents. In these cases XFS tries to 
allocate large arrays of xfs_ext_irec_t structure with kmalloc, and this 
often gets into numerous retries, and sometimes triggers hung task panic 
(due to some other thread wanting to access the same file).

We made a change to call kmem_zalloc_large, which resorts to __vmalloc in 
case kmalloc fails. kmem_free is already handling vmalloc addresses 
correctly. The change is only for the allocation done in 
xfs_iext_realloc_indirect, as this is the only place, in which we have seen 
the issue.

Final code, as usual, will be in 
https://github.com/zadarastorage/zadara-xfs-pushback

Thanks,
Alex.


-----Original Message----- 
From: Dave Chinner
Sent: Friday, July 24, 2015 2:09 AM
To: Alex Lyakas
Cc: Christoph Hellwig ; Danny Shavit ; bfoster at redhat.com ; Yair Hershko ; 
Shyam Kaushik ; xfs at oss.sgi.com
Subject: Re: xfs_iext_realloc_indirect and "XFS: possible memory allocation 
deadlock"

On Thu, Jul 23, 2015 at 05:39:28PM +0200, Alex Lyakas wrote:
> Hi Dave,
> Just for completeness,  XFS speculative preallocation (that is based
> now upon the size of the last extent) can still grow up to 4Gb-8Gb
> (depending on which patches we are pulling). As a result, xfs_iozero
> can still sometimes trigger 1-2GB writes of zeros in one shot. This
> turns out to be a bit unfriendly to the drives in some
> configurations. So we have applied a custom patch to limit the
> speculative preallocation to 32Mb.

It would be much better to change xfs_zero_eof() to convert extents
beyond EOF to unwritten extents rather than zero them. That way you
still get the benefits of the large speculative prealloc but without
the zeroing overhead that wierd sparse write patterns can trigger.

I just haven't got around to doing this because it hasn't been
reported as a significant problem for anyone until now.

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com