I wonder how much this improves performance over not "JIT'ing" the calculation. I have done similar things in image/video codec code (where it resulted in substantial increases in speed) but this is the first time I've seen it for a filesystem.
https://lore.kernel.org/linux-bcachefs/ZGB1eevk%2Fu2ssIBT@mo...
[...]
testing random btree updates:
dynamically generated unpack:
rand_insert: 20.0 MiB with 1 threads in 33 sec, 1609 nsec per iter, 607 KiB per sec
old C unpack:
rand_insert: 20.0 MiB with 1 threads in 35 sec, 1672 nsec per iter, 584 KiB per sec
the Eric Biggers special:
rand_insert: 20.0 MiB with 1 threads in 35 sec, 1676 nsec per iter, 583 KiB per sec
[...]They have engineers dedicated to 0.5-2.0% improvements in the kernel
All in all, while a good Phoronix benchmark is what can make it supplant all other Linux filesystems, I appreciate the security concerns raised by maintainers, and I agree that a better approach would have been to use the default code at first, and seek advice on how to improve its performance. Thankfully, it looks like that is where it is going now.