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.
Most excitingly is a big I/O performance improvement for RedoxFS via implementing records support. The status report explains of the I/O performance work for RedoxFS:
RedoxFS in February also saw code clean-ups to the network driver and kernel, Relibc continues becoming more fruitful, Boxedwine is being ported as an older Wine downstream (Wine 1.8 to Wine 5.0 support) for running 16/32-bit Windows programs, an option to use the NVMe interface of QEMU, and other improvements.
More details on these latest RedoxOS Rust operating system happenings via Redox-OS.org.
Most excitingly is a big I/O performance improvement for RedoxFS via implementing records support. The status report explains of the I/O performance work for RedoxFS:
In order to separate the size of RedoxFS read/write operations from the disk block size, the concept of “records” was introduced, where the record size is a power of two multiple of the block size.
For large files, a record size of 128KiB was chosen, as this gives a good balance between sequential access and random access speeds.
As an anecdotal example, command start-up time for the first run of a large program is about 3 times faster than previously.
4lDO2 discovered a related optimization opportunity.
In the Rust standard library, the default buffer size for most built-in read/write APIs, including std::io::copy, is 8KiB.
If you copy a 30 MiB file with an 8 KiB buffer size, the process will take 3840 scheme call roundtrips to complete. This could take a long time if there are other processes competing for CPU time in the scheduler. This is because Redox doesn’t support direct context switching yet, and dd doesn’t use parallelized or batched I/O.
Redox hasn’t yet specialized std::fs::copy, which uutils’s cp program uses directly. Linux and MacOSX have an optimization (fclonefileat/clone_file_range) that allows a larger buffer size, which can be optimized more aggressively.
We plan to implement this in relibc in the near future.
The record size optimization is an example of low-hanging fruit for performance improvements. We still have many other improvements planned, and will do our best to keep you up to date.
RedoxFS in February also saw code clean-ups to the network driver and kernel, Relibc continues becoming more fruitful, Boxedwine is being ported as an older Wine downstream (Wine 1.8 to Wine 5.0 support) for running 16/32-bit Windows programs, an option to use the NVMe interface of QEMU, and other improvements.
More details on these latest RedoxOS Rust operating system happenings via Redox-OS.org.
29 Comments