On Thu, Jan 25, 2018 at 08:08:31AM -0500, Brian Foster wrote: > I suppose it's possible that this was some kind of transient state, or > perhaps only a small set of AGs are affected, etc. It's also possible > this may have been improved in more recent kernels by Christoph's rework > of some of that code. In any event, this would probably require a bit > more runtime analysis to figure out where/why allocations are getting > stalled as such. I'd probably start by looking at the xfs_extent_busy_* > tracepoints (also note that if there's potentially something to be > improved on here, it's more useful to do so against current upstream). > > Or you could just move to something that supports RWF_NOWAIT.. ;) The way the XFS allocator works has always had a fundamental flaw since we intorduced the ocncept of busy extents, and that is we need to lock ourselves into an AG or sometimes even range without taking said busy extents into account. The proper fix is to separate the in-core and in-memory data structures for free space tracking, and only release the busy extents to the in-memory one once they aren't busy anymore. Looking into this has been on my todo list for a long time, but I never go to it. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
