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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
