manifault

Note: Phoronix incorrectly reported this as a rust scheduler. There's a very small user space component written in rust, but the vast majority of the actual scheduling logic is written in C (i.e. as the BPF program) which runs in kernel space: https://github.com/sched-ext/scx/blob/main/scheds/rust/scx_l...

Thanks for the vote of confidence! We agree, and have had a great time writing it. If you'd like to play around with it, take a look at https://github.com/sched-ext/scx. LWN wrote a nice article on this as well a while back: https://lwn.net/Articles/922405/.

>There are absolutely things I'd be comfortable writing in Rust and not in C because I'd very likely mess up the C implementation. Rust encourages and lowers the cost for certain algorithms and implementations.

I share your sentiment, but that's not really relevant here. The kernel portion of the scheduler is written in C -- as are all of the other example (and production) schedulers we wrote. The BPF verifier ensures that the program is safe and can't crash the kernel, and we have a watchdog that will boot out a buggy scheduler that fails to schedule tasks in a timely manner.

>But even apart from that, the implementation being different doesn't matter much I think? I think it's more about there being a compelling component existing in rust, and less about whether it could be a different language or not.

An understandable point of confusion, but this is not the case. The fact that the user space portion of scx_rustland is written in rust is anecdotal. We have other schedulers which are entirely contained in the kernel, and others which have rich user space logic written in C. Many of them outperform EEVDF in a lot of different scenarios. By way of example, we're running a C scheduler now for Meta web workloads because it outperforms EEVDF by several percent for both latency and throughput.

Correct -- the purpose of the watchdog is to account for buggy schedulers that fail to schedule runnable tasks. scx_rustland has special logic to track the user-space scheduling task, though. If it incorrectly failed to schedule it when it had no more runnable tasks to run, then the watchdog would eventually kick in, boot out scx_rustland, and revert back to EEVDF.

The scx_userland scheduler itself knows which task in user space is the scheduler task, and schedules it when it doesn't have any more runnable tasks to dispatch from the kernel: https://github.com/sched-ext/scx/blob/main/scheds/rust/scx_r...

Sorry? This is completely false. It is highly CPU bound. Especially front-end CPU pipeline bound.

Sure, whatever. "Offloading" was perhaps a poor choice of wording, but it is related to the standardization efforts. The NVMe vendors don't want to be calling out to BPF programs in the driver if the runtime semantics are not standardized.

I'm not closely tied to what the NVMe vendors want, so you could be right, but I very much doubt you are given that Christoph didn't flag this when he reviewed the article.

Edit: And to be clear, from my understanding of XRP, the device itself calls back into a BPF function in the NVMe driver. That requires some notion of standardization. It's not exactly offloading directly to the storage device, but the storage device still relies on some standardized behavior in the BPF program, such as divide by zero, what instructions are supported in the ISA, etc.

Not sure if there's a full user space runtime for BPF progs, but there are lots of user space tools which are useful for working with BPF progs. For example, you can use veristat (https://github.com/libbpf/veristat) to easily see whether a BPF prog would be verified, and collect statistics, etc.