(trimmed cc:)

On 01/18/16 11:25, Martin Steigerwald wrote:

Chris,

Am Sonntag, 17. Januar 2016, 18:30:34 CET schrieb Chris Mason:

quoted

For very large filesystems (30T+) our existing free space caching code
can end up taking a huge amount of time during commits.  The new tree
based code is faster and less work overall to update as the commit
progresses.

Will be interesting to see whether this also helps with:

[Bug 90401] New: btrfs kworker thread uses up 100% of a Sandybridge core for 
minutes on random write into big file

Unlikely, because the fst addresses something entirely different. It's much
more likely that whatever CPU spinning was going on there was addressed by
Josef's allocator fixes in 4.4 [1], which removed a lot of looping and
unnecessary/repeated work.

-h

[1] https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/log/?h=for-linus-4.4&ofs=50