tag name | bcachefs-2024-08-23 (ee2f36ad6cf7cbc10380b4e62960168d25a9cfea) |
tag date | 2024-08-23 10:55:07 -0400 |
tagged by | Kent Overstreet <kent.overstreet@linux.dev> |
tagged object | commit 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-----