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

[Dave Chinner <david@fromorbit.com>]

On Tue, Apr 05, 2016 at 09:10:06PM +0300, Alex Lyakas wrote:
> 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.

As I've said before, vmalloc is not a solution we can use in
general.  32 bit systems have less vmalloc area than normal kernel
memory (e.g. ia32 has 128MB of vmalloc space vs 896MB of kernel
address space by default) and hence if we get large vmap allocation
requests for non-temporary, not directly reclaimable memory then
we'll end up with worse problems than we already have due to vmalloc
area exhaustion.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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