On Tue, Oct 08, 2019 at 03:46:18PM +0300, Nikolay Borisov wrote: > > > On 7.10.19 г. 23:17 ч., Dennis Zhou wrote: > > Async discard will use the free space cache as backing knowledge for > > which extents to discard. This patch plumbs knowledge about which > > extents need to be discarded into the free space cache from > > unpin_extent_range(). > > > > An untrimmed extent can merge with everything as this is a new region. > > Absorbing trimmed extents is a tradeoff to for greater coalescing which > > makes life better for find_free_extent(). Additionally, it seems the > > size of a trim isn't as problematic as the trim io itself. > > > > When reading in the free space cache from disk, if sync is set, mark all > > extents as trimmed. The current code ensures at transaction commit that > > all free space is trimmed when sync is set, so this reflects that. > > > > Signed-off-by: Dennis Zhou <dennis@xxxxxxxxxx> > > I haven't looked closely into this commit but I already implemented > something similar in order to speed up trimming by not discarding an > already discarded region twice. The code was introduced by the following > series: > https://lore.kernel.org/linux-btrfs/20190327122418.24027-1-nborisov@xxxxxxxx/ > in particular patches 13 to 15 . > > Can you leverage it ? If not then your code should, at some point, > subsume the old one. > I spent some time reading through that. I believe we're tackling two separate problems. Correct me if I'm wrong, but your patches are making subsequent fitrims faster because it's skipping over free regions that were never allocated by the chunk allocator. This series is aiming to solve intra-block group trim latency as trim is handled during transaction commit and consequently also help prevent retrimming of the free space that is already trimmed. Thanks, Dennis
