Hacker News Reader

Comment by cwillu | Hacker News Reader

Looks like 5% on the benchmark in the (long) thread.

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
    [...]

View on HN

5% is way too little to risk mainlining over

Alternative: 5% gain in a specific issue is totally fine to defer until another patch set. It feels like fighting about it in the first submission is a waste of time for everyone involved.

You said it the way I'd want to.

Agreed, extraordinary solutions require extraordinary justification.

5% can be tens of millions of dollars a year when you're FAANG scale

They have engineers dedicated to 0.5-2.0% improvements in the kernel

Yes and those improvements can happen in due time, after the filesystem first has arrived in linux.

What does mainlining mean in this context?

Merging into the main Linux branch (Linus’). One maintainer has said they won’t merge until the JIT is removed. If it is never merged to Linux, it will forever be niche, requiring the same tricks and having the same limitations as zfs.ko. So it seems better to be 5% slower now and widely used, than to always be niche.

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.

Reply on news.ycombinator.com