[swsieber]

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.

Whether or not that's the case here, I don't know. I wouldn't expect it to be the case here though.

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.

[manifault]

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

[nkozyra]

> I think it's more about there being a compelling component existing in rust

Isn't the interesting part that there's a scheduler that's way better particularly in this use case? Linux is taking in Rust here and there already, I don't think that alone is interesting and the parent point is that the same thing could have been written in C.

There are compelling reasons to choose Rust, but it's not magically fixing performance by virtue of not being C. In which case, the implementation is the story.

[swsieber]

> Linux is taking in Rust here and there already, I don't think that alone is interesting and the parent point is that the same thing could have been written in C.

I'm not sure if you mean "Linux taking in Rust is not interesting" or "This component in Rust (apart from implementation details) is interesting", but I absolutely think both are interesting.

For the first (which you may agree with, IDK), Linux has refused to take C++, etc. as languages.

For the second, my understanding is that the kernel support was kind of a provisional trial integration of Rust, and that no essential components were to be written in Rust. Now an alternate scheduler isn't a an essential component, but it the first thing I've heard of that would get me to compile a rust component for the kernel.

Edit: wait, wait, wait, this is eBPF driven? Does that even need the kernel linux support? This becomes even more interesting to me. Sounds like we could maybe see eBPF filters Go or Nim soon if that's the case.

[marcosdumay]

Nah, the existence of a scheduler that performs some workload better than the generic one isn't very interesting. It's a well known fact that specialized schedulers perform better. It's just that the generic one advanced enough so that it's not worth switching for most people, but that's only after you look at the hassle of managing them.

What is really interesting here is the central piece of the kernel written on Rust, and working perfectly fine.

[johnisgood]

That is exactly what I meant, thank you. That said, I would like to know the differences in those implementation details as to why it outperforms the default scheduler.