summaryrefslogtreecommitdiff
tag namebcachefs-2024-08-23 (ee2f36ad6cf7cbc10380b4e62960168d25a9cfea)
tag date2024-08-23 10:55:07 -0400
tagged byKent Overstreet <kent.overstreet@linux.dev>
tagged objectcommit 4d8ead60ff...
bcachefs fixes for 6.11-rc5
Lots of little fixes and two big items, which were orgiinally slated for the 6.12 merge window but turned out to be pretty important. The little stuff includes assorted syzbot fixes and some upgrade fixes for old (pre 1.0) filesystems, and a fix for moving data off a device that was switched to durability=0 after data had been written to it. The big items are: - rhashtable conversion for VFS inodes cache Thas was slated for the 6.12 merge window, but a deadlock was uncovered in __wait_for_freeing_inode(); bcachefs inverts the usual locking between the VFS inode cache and on disk (btree) locking, with some advantages and some extra trickyness. The result was that we were waiting (via __wait_for_freeing_inode()) on the evict -> clear_inode() path with btree locks held, which was a rare deadlock but undoubtedly also one of the sources of the SRCU warnings. - new data structure for managing freelists in btree key cache This eliminates the btree key cache lock, and associated lock contention. User feedback is that this resolves the main source of the SRCU warnings we've been seeing - which means that on some of the big multithreaded workloads people are running the lock contention was really bad (threads piling up and causing O(n^2) wait times), if it was able to trigger a 10 second delay warning. On the test reported by https://lore.kernel.org/linux-bcachefs/CAGudoHGenxzk0ZqPXXi1_QDbfqQhGHu+wUwzyS6WmfkUZ1HiXA@mail.gmail.com/ We're now 4x faster than xfs on creatrees, roughly even on walktrees, with consistent run to run performance; dominant factor in profiles is lru lock contention. -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEKnAFLkS8Qha+jvQrE6szbY3KbnYFAmbI2Q8ACgkQE6szbY3K bnZWUA//RBSaFDm3/qHwkWkzTiWFwOU2aF7386ruHa43rom0i8njMbgGqlmuRtCi 6vPWFYt8JTFaUhR0ocSTRiOMEtJc7x0JD8ugaFmM+hUsHYmGy6ThymO12Loko3XL qvpkoH0uH+8+UbJclDq37XCOQ5PahpODw0337J1V+tnI4ogQdqVbhoTNKo06QG2b 7ikBMihs0lm4APBPAPFpK3W53caVIMlk0s/HVnKvctjqseBRQgA2u6nzM3Hlan5n 8bKJoMsFHQC0zlj4Hjiu1lORHnilV4o0hVBfz2BmQ9VPybD/N4tfD0HZtBGgaPCc xfxjTnKyCz61SrJcxKPmzOMLO0Nkq1tq1Q7sT8gPNowptb/IbEuDf6B2PUkIJ2yj zZ6JJ5jHZzJ+RK9M7nir9DhdIPFf3LGzSECfyXBaDi+W/Bhpi9ShI3IoWNgh9rNI YZfLsBq2Ht7AV4uwcZqPaI7E38OuEplO4Bbw36/ZfT1LNGlcm0A8juzCXFpc0h5H S0KBdBWCsg9i/0zOAlCwzmc84sSqeicgztylYlaittOo4SDn1wRvY1vCq2L9lQX+ oaVeU4OdpltM+zPEXP02as3h8idQNe9Kpg7m69GRSHnAKu+1dNAmd4I2mRh6kCBR jZrkvH/wjOhBnagZzcRqmE475vawkENt7GewOb0o0IKIVzLBLBk= =8Kkm -----END PGP SIGNATURE-----