(trimmed cc:) On 01/18/16 11:25, Martin Steigerwald wrote: > Chris, > > Am Sonntag, 17. Januar 2016, 18:30:34 CET schrieb Chris Mason: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
