Redox OS Scores A Massive Performance Boost For I/O

[phoronix]

Phoronix: Redox OS Scores A Massive Performance Boost For I/O

The Rust-written Redox OS is out with a new monthly status report to outline the enhancements made to this open-source operating system during the month of February...

https://www.phoronix.com/news/Redox-OS-Faster-IO

[geerge]

Honestly I'm unlikely to ever use redox os but i like it when people make number go brrrrr.

[tildearrow]

In the Rust standard library, the default buffer size for most built-in read/write APIs, including std::io::copy, is 8KiB.

"Rust is blazing fast"
To be fair, 8KB is fine for most tasks, but why doesn't it scale depending on how big the input buffer is?

[Quackdoc]

now we just need to wait for bcachefs redox

[intelfx]

now we just need to wait for bcachefs redox

Jokes aside, if Kent goes ahead with his plan of aggressively adopting Rust in Bcachefs, this may well just happen.

[pabloski]

Jokes aside, if Kent goes ahead with his plan of aggressively adopting Rust in Bcachefs, this may well just happen.

The problem is that it needs Linux specific functions and subsystems. Unless someone ports Bcachefs to RedoxOS ( unlikely ). So please no, I am already crying because of LinuxBSD ( FreeBSD implementing more and more Linux subsystems ). I hope those OSes remain independent and maintain their personality.

[Quackdoc]

The problem is that it needs Linux specific functions and subsystems. Unless someone ports Bcachefs to RedoxOS ( unlikely ). So please no, I am already crying because of LinuxBSD ( FreeBSD implementing more and more Linux subsystems ). I hope those OSes remain independent and maintain their personality.

see the and ofc part below

Jokes aside, if Kent goes ahead with his plan of aggressively adopting Rust in Bcachefs, this may well just happen.

thankfully I do believe he is doing this, and ofc since it's rust, you could easily just abstract platform specific stuff to it's own crate to keep performance, not everything would play nicely ofc, but it would help quite a bit most likely. you can ofc do this with C/C++ too, but doing this is just simply more common with rust projs for some reason

[intelfx]

The problem is that it needs Linux specific functions and subsystems. Unless someone ports Bcachefs to RedoxOS ( unlikely ). So please no, I am already crying because of LinuxBSD ( FreeBSD implementing more and more Linux subsystems ). I hope those OSes remain independent and maintain their personality.

Unfortunately, what's "maintaining personality" to one is "unnecessary fragmentation" to another (and also "forcing programs to the lowest common denominator if they wish to be portable" to yet others).

However, in case of filesystems, I'm pretty sure that platform specific stuff can and will be abstracted if there's ever an actual desire to bring bcachefs to redox.

[Vorpal]

So I see quite a bit of questions and confusion in this thread ( tildearrow geerge ) :

1. Why 8 kb? When reading data and processing it there is a tradeoff between size of days you load at a time and CPU cache size(s). You *could* load 200 MB in one go and then process it, but then the data would be all cold in the cache again. It might make more sense to read 8 or 16 kb at a time so you have a "hot" buffer. You probably don't want your entire cache to be used for the buffer, it depends on how much ram your algorithm requires (and the file system code in the kernel, etc as well of course) .

I ran into this when trying to do checksum verification (sha256) on many files as fast as possible. After benchmarking on my specific system 16 kb was marginally faster than 8 kb, and both were marginally faster than 32 kb. My cpu has 32 kb L1d cache (I need some memory to keep the actual sha256 state too), so this makes sense. I only tested power of 2 sizes. I should emphasise "marginally" here, I had to turn off all CPU frequency scaling etc, stop background processes and so on for the difference to become visible from the noise (I used hyperfine for statistically rigorous measurements).

For a different task you may want a different size. Same for different hardware.

2. File copying. Not doing something is always faster (thus the mention of making the kernel do it without copying into user space at all). File copying at its lowest and most optimised level will involve DMA copies between storage devices (or within, I think that might exist on some enterprise devices, not needing to round trip to RAM at all!). Plus some handling of metadata for the file entry itself of course. Of course in this context CPU cache doesn't matter (the whole point of DMA is that the CPU isn't copying, it is asking the device to do it). So larger buffers make sense.

Even when you don't optimise it in the kernel (but round trip via user space), user space won't actually be processing the buffer, so CPU cache size is still largely irrelevant. Thus larger buffers make sense.

3. Syscall overhead. This famously increased a lot after meltdown/spectre mitigations, which may have changed the optimal point towards larger buffers. But more importantly in this case is that Redox uses a micro kernel design. This causes more round trips since here the file system is just another user space process that you are talking to via things provided by the kernel. That in turn talks to another process which is the block driver. This adds overhead. This is inherent to micro kernels. Great for security and modularity though.

Are there ways to optimise this? Maybe, proponents say that it can be done, but monolithic kernel still dominates outside some very specific niches. Mac OS X is based on a micro kernel (XNU) that over the years morphed into a monolithic kernel for performance reasons.

Those numbers in the article also seem awfully low to me, but I don't know what hardware this ran on, if it was in a VM, etc. And redoxos does not have the tens of thousands of man hours that have been spent on the Linux kernel, at least not yet.

I'm not knowledgeable enough to make a call either way on this one.

[mirmirmir]

How does it compare to Linux? It got to be more performant for such a headline