On Mon, Nov 05, 2018 at 01:51:39PM -0800, Christoph Hellwig wrote: > On Mon, Nov 05, 2018 at 01:10:21PM -0500, Brian Foster wrote: > > When online discard is enabled, discards of busy extents are > > submitted asynchronously as a bio chain. bio completion and > > resulting busy extent cleanup is deferred to a workqueue. Async > > discard submission is intended to avoid blocking log forces on a > > full discard sequence which can take a noticeable amount of time in > > some cases. > > > > We've had reports of this still producing log force stalls with XFS > > on VDO, > > Please fix this in VDO instead. We should not work around out of > tree code making stupid decisions. I assume the "stupid decision" refers to sync discard execution. I'm not familiar with the internals of VDO, this is just what I was told. My understanding is that these discards can stack up and take enough time that a limit on outstanding discards is required, which now that I think of it makes me somewhat skeptical of the whole serial execution thing. Hitting that outstanding discard request limit is what bubbles up the stack and affects XFS by holding up log forces, since new discard submissions are presumably blocked on completion of the oldest outstanding request. I'm not quite sure what happens in the block layer if that limit were lifted. Perhaps it assumes throttling responsibility directly via queues/plugs? I'd guess that at minimum we'd end up blocking indirectly somewhere (via memory allocation pressure?) anyways, so ISTM that some kind of throttling is inevitable in this situation. What am I missing? Brian
