9 ms·

Rust-Written Linux Scheduler Showing Promising Results for Gaming Performance

98 points by electricant 3y ago

johnisgood 3y ago
What is the implication here, or what is it trying to say? If it outperforms C, then it obviously has very different implementation details, including algorithms and whatnot. It does not outperform the scheduler because it is written in Rust.
- knorker 3y ago
  I read this as a validating use case, showing that real kernel use cases can be written in Rust, without seeming temporary in an unserious language until the real code can be written. Can the same algorithm be written in C? Sure, but it could also have been written in assembly.
- swsieber 3y ago
  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.
  - nkozyra 3y ago
    > 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.
    - johnisgood 3y ago
      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.
    - swsieber 3y ago
      > 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 3y ago
      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.
  - manifault 3y ago
    >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.
- celrod 3y ago
  To be clear, this doesn't mean this scheduler itself runs faster. It means that the scheduler algorithm is better suited for gaming workloads, allocating your hardware more effectively. Of course, if the scheduler ran much slower so your CPU spends more time on the scheduler than time saved through better resource allocation, then it wouldn't help performance. But that's hopefully not a major factor here.
antirez 3y ago
Are we at this level now? The scheduler performance has nothing to do with the used language. Actually making use of the freedom C provides (while being unsafe) you have the ability to implement whatever complex algorithm you can envision in the most direct way. Moreover scheduling is all about tradeoffs: it's not hard to write a scheduler that is better than a genera purpose one for a specific task. If you like Rust write your code in Rust but the community should stop with this kind of attitude.
- electricant 3y ago
  Well it's not just about Rust. What we have here is pluggable schedulers leveraging the BPF functionality within the linux kernel. They can be written in watever language you like and they are running in the user space.
  - SpaceNugget 3y ago
    eBPF doesn't run in user space in the context of eBPF in the linux kernel. It's verified so that the kernel can be sure it won't loop forever and then gets JIT'ed and run in kernel space. There are some user space BPF vms like https://github.com/iovisor/ubpf https://github.com/iovisor/ubpf and Solana.
- knorker 3y ago
  1. It's interesting that Rust is not just viable in some less important kernel code, but possible in core components. 2. C isn't necessarily the best language for performance. Specifically it's not very good about letting the compiler make assumptions about aliasing. Same reason some CPU-heavy stuff tended to use (ugh) Fortran[1]. Rust is better than C in giving the compiler access to this information for optimization. But I think you read the article and the post wrong. It's not "ha ha, C suxx", it's just... interesting. [1] I say "tended", because presumably nowadays it's optimized for GPUs, and I've not been keeping up.
- Aurornis 3y ago
  > Are we at this level now? The scheduler performance has nothing to do with the used language. The whole project is a toy and they’re not trying to hide it. The mention of the language is just a descriptor for the project, not an implication that Rust is faster.
_ZeD_ 3y ago
I think the important bit here is: a Linux scheduler written "during Christmas break, just for fun", is better that the current one. it might be the developer sense of "fun", it might be rust, but it is impressive, notheless
- flohofwoe 3y ago
  ...is better for one specific workload scenario. It's actually baffling that the default scheduler doesn't seem to boost the priority of the 'active window process'.
  - mariusor 3y ago
    The linux kernel has no concept of "active window process". It has the concept of "current process", and deciding which process that is, is exactly the job of the scheduler. :P
    - mplanchard 3y ago
      I'd love to see more focus on this in the Linux scheduler, at least allowing an optional mode for interactive use. It's frustrating to have my entire system occasionally grind to a halt because of compilation or a particularly beefy test suite.
      - mariusor 3y ago
        That's what (in)famous kernel dev Con Kolivas[1] was doing up to late noughties. I'm not sure if he's still active in maintaining out of tree schedulers though. [1] https://en.wikipedia.org/wiki/Con_Kolivas#Linux https://en.wikipedia.org/wiki/Con_Kolivas#Linux
- Karellen 3y ago
  > a Linux scheduler written "during Christmas break, just for fun", is better that the current one. ...with certain workloads i.e. it might be a bit better in a few specific cases, but a bit worse in a large number of more common workloads. Not that I'm trying to take anything away from the work - getting on par with the well-tuned-over-many-years scheduler for any workloads is an impressive feat. But saying it's "better than the current one" without the caveats made by the original author is oversimplifying to the point of being misleading, I think.
bluejekyll 3y ago
"I ended up writing a Linux scheduler in Rust using sched-ext during Christmas break, just for fun. I'm pretty shocked to see that it doesn't just work, but it can even outperform the default Linux scheduler (EEVDF) with certain workloads (i.e., gaming)." — Andrea Righi I think that pretty clearly summarizes the entire reason for doing this and the excitement that it works and works well.
- westhanover 3y ago
  I don’t understand why he measured the performance gain like he did. Playing a game with a background kernel compile running is a very unique gaming benchmark.
  - wsc981 3y ago
    You have to do something while compiling a Linux kernel, might as well play a game as (I imagine) it can take a while :)
    - rkangel 3y ago
      Depends what you're compiling. A kernel for embedded (and therefore a trimmed down set of modules) on a decent machine can easily just be a minute or two. The kernel build system is pretty good at incremental compilation as well.
  - ta8645 3y ago
    It's akin to running any CPU intensive task while playing a game... The hope would be to make the most progress possible without stalling the foreground process.
    - jacquesm 3y ago
      A kernel compile is not CPU bound.
      - antiframe 3y ago
dijit 3y ago
I would like to stem a little bit of sentiment here. I can write a toy program that saves files to disk much faster than notepad.exe, but this is a consequence of making fewer decisions and handling fewer edge cases. It's trivial to make fast software, especially toy software, but they tend not to survive practical applications without becoming as slow or slower than the systems they originally mimic. That said: that it works is really cool.
rumdz 3y ago
You can swap out the scheduler dynamically using eBPF!? That's incredible.
- soulbadguy 3y ago
  Yeah, i was surprise to read that. For me that a way bigger deal than the language used...
- tuetuopay 3y ago
  this blew my mind. all people are arguing whether rust is a good fit, a strike force, or if a game is a good benchmark. the whole point of this is that one guy can write a scheduler during winter break and friggin hot swap it at runtime while a compile and a game can run. this is the newsworthy part. dang it, I want to try it now. and make an article stating I did it in Zig for the clicks!
- manifault 3y ago
  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 https://github.com/sched-ext/scx. LWN wrote a nice article on this as well a while back: https://lwn.net/Articles/922405/ https://lwn.net/Articles/922405/.
flohofwoe 3y ago
That such a simple 2D game isn't able to reach 60fps under heavy system load just shows that the vanilla scheduler doesn't boost the process associated with the currently active window though? Shouldn't this be standard on all 'desktop' operating systems, e.g. anything associated with the user gets higher priority than anything else happening on the system? Even the Amiga had such a priority-boosting system back in 1985 (otherwise multitasking wouldn't be of much use on such a slow computer, because pretty much any background task would make the UI unusable).
- mariusor 3y ago
  How would the vanilla scheduler know which process is associated with the currently active window? You're assuming there's more cooperation between the various layers of a linux desktop than I think there really are.
  - flohofwoe 3y ago
    One would think that at least a rewrite-from-scratch effort like Wayland would have come up with a solution. Unfortunately the same problem also exists on other systems. Visual Studio even had to add a feature "Run build at low process priority" for the system to remain usable during builds: https://devblogs.microsoft.com/cppblog/msbuild-low-priority-builds-in-visual-studio https://devblogs.microsoft.com/cppblog/msbuild-low-priority-...
    - mariusor 3y ago
      I mean the end-user can always write the glue required to get the current running window get its process and mark that as the "high priority", but that's still working under the constraints of the regular scheduler.
  - soulbadguy 3y ago
    The scheduler doesn't need to know which process is associated with the currently active windows. Simple heuristics can get you which to "reasonably" guesstimate which process are interactive and which aren't. For example, every X and descendant, or everything waiting on keyboard/controller or any other input. I think the linux kernel historically did not want to prioritize interactive processes like windows and macos does. The other thing is of course to reduce the CPU quanta, trading latency for throughput. I think most modern distribution do ship with better quanta for smooth GUI/desktop behavior.
amluto 3y ago
> For production scenarios, other schedulers are likely to exhibit better performance, as offloading all scheduling decisions to user-space comes with a certain cost. Aside from possibly increased scheduler latency, there’s the rather larger potential cost of outright deadlocks: what guarantees that the user scheduler task runs at all when it’s needed? On 60 seconds of skimming the repo, I didn’t spot a specific solution to this problem. I wonder how it was addressed. Or maybe it wasn’t, since this is just an experiment.
- loeg 3y ago
  At least in one version of the documentation patch, there's mention of a watchdog timeout that unloads the user scheduler if it fails to make forward progress for some period of time. https://www.uwsg.indiana.edu/hypermail/linux/kernel/2307.1/02300.html https://www.uwsg.indiana.edu/hypermail/linux/kernel/2307.1/0...
  - manifault 3y ago
    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.
- manifault 3y ago
  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_rustland/src/bpf/main.bpf.c#L450-L468 https://github.com/sched-ext/scx/blob/main/scheds/rust/scx_r...
  - amluto 3y ago
    Hah, I should have spent 120 seconds searching :)
DeathArrow 3y ago
Had this scheduler not been written in Rust, would it still have ended up on HN?
- RedlineTriad 3y ago
  Hard to answer, but I was interested because I assumed it built on the "recent" work to bring rust into the kernel. Where I haven't read much news about how it is being used except for Asahi Linux. Somewhat disappointed that it is using eBPF instead, but still interesting to learn that even such fundamental and performance sensitive parts such as the scheduler can be changed.
- ksec 3y ago
  If you mean submission to HN then yes because I would have submitted it. If you mean ended up on HN as in front page of HN, then definitely no.
up2isomorphism 3y ago
Highly doubt subpar Linux gaming experience is due to its scheduler implementation.

98 points by electricant 3y ago

What is the implication here, or what is it trying to say? If it outperforms C, then it obviously has very different implementation details, including algorithms and whatnot. It does not outperform the scheduler because it is written in Rust.

knorker 3y ago
I read this as a validating use case, showing that real kernel use cases can be written in Rust, without seeming temporary in an unserious language until the real code can be written. Can the same algorithm be written in C? Sure, but it could also have been written in assembly.
swsieber 3y ago
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.
- nkozyra 3y ago
  > 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.
  - johnisgood 3y ago
    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.
  - swsieber 3y ago
    > 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 3y ago
    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.
- manifault 3y ago
  >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.
celrod 3y ago
To be clear, this doesn't mean this scheduler itself runs faster. It means that the scheduler algorithm is better suited for gaming workloads, allocating your hardware more effectively. Of course, if the scheduler ran much slower so your CPU spends more time on the scheduler than time saved through better resource allocation, then it wouldn't help performance. But that's hopefully not a major factor here.

antirez 3y ago

Are we at this level now? The scheduler performance has nothing to do with the used language. Actually making use of the freedom C provides (while being unsafe) you have the ability to implement whatever complex algorithm you can envision in the most direct way. Moreover scheduling is all about tradeoffs: it's not hard to write a scheduler that is better than a genera purpose one for a specific task. If you like Rust write your code in Rust but the community should stop with this kind of attitude.

electricant 3y ago
Well it's not just about Rust. What we have here is pluggable schedulers leveraging the BPF functionality within the linux kernel. They can be written in watever language you like and they are running in the user space.
- SpaceNugget 3y ago
  eBPF doesn't run in user space in the context of eBPF in the linux kernel. It's verified so that the kernel can be sure it won't loop forever and then gets JIT'ed and run in kernel space. There are some user space BPF vms like https://github.com/iovisor/ubpf https://github.com/iovisor/ubpf and Solana.
knorker 3y ago
1. It's interesting that Rust is not just viable in some less important kernel code, but possible in core components. 2. C isn't necessarily the best language for performance. Specifically it's not very good about letting the compiler make assumptions about aliasing. Same reason some CPU-heavy stuff tended to use (ugh) Fortran[1]. Rust is better than C in giving the compiler access to this information for optimization. But I think you read the article and the post wrong. It's not "ha ha, C suxx", it's just... interesting. [1] I say "tended", because presumably nowadays it's optimized for GPUs, and I've not been keeping up.
Aurornis 3y ago
> Are we at this level now? The scheduler performance has nothing to do with the used language. The whole project is a toy and they’re not trying to hide it. The mention of the language is just a descriptor for the project, not an implication that Rust is faster.

_ZeD_ 3y ago

I think the important bit here is: a Linux scheduler written "during Christmas break, just for fun", is better that the current one. it might be the developer sense of "fun", it might be rust, but it is impressive, notheless

flohofwoe 3y ago
...is better for one specific workload scenario. It's actually baffling that the default scheduler doesn't seem to boost the priority of the 'active window process'.
- mariusor 3y ago
  The linux kernel has no concept of "active window process". It has the concept of "current process", and deciding which process that is, is exactly the job of the scheduler. :P
  - mplanchard 3y ago
    I'd love to see more focus on this in the Linux scheduler, at least allowing an optional mode for interactive use. It's frustrating to have my entire system occasionally grind to a halt because of compilation or a particularly beefy test suite.
    - mariusor 3y ago
      That's what (in)famous kernel dev Con Kolivas[1] was doing up to late noughties. I'm not sure if he's still active in maintaining out of tree schedulers though. [1] https://en.wikipedia.org/wiki/Con_Kolivas#Linux https://en.wikipedia.org/wiki/Con_Kolivas#Linux
Karellen 3y ago
> a Linux scheduler written "during Christmas break, just for fun", is better that the current one. ...with certain workloads i.e. it might be a bit better in a few specific cases, but a bit worse in a large number of more common workloads. Not that I'm trying to take anything away from the work - getting on par with the well-tuned-over-many-years scheduler for any workloads is an impressive feat. But saying it's "better than the current one" without the caveats made by the original author is oversimplifying to the point of being misleading, I think.

bluejekyll 3y ago

"I ended up writing a Linux scheduler in Rust using sched-ext during Christmas break, just for fun. I'm pretty shocked to see that it doesn't just work, but it can even outperform the default Linux scheduler (EEVDF) with certain workloads (i.e., gaming)." — Andrea Righi I think that pretty clearly summarizes the entire reason for doing this and the excitement that it works and works well.

westhanover 3y ago
I don’t understand why he measured the performance gain like he did. Playing a game with a background kernel compile running is a very unique gaming benchmark.
- wsc981 3y ago
  You have to do something while compiling a Linux kernel, might as well play a game as (I imagine) it can take a while :)
  - rkangel 3y ago
    Depends what you're compiling. A kernel for embedded (and therefore a trimmed down set of modules) on a decent machine can easily just be a minute or two. The kernel build system is pretty good at incremental compilation as well.
- ta8645 3y ago
  It's akin to running any CPU intensive task while playing a game... The hope would be to make the most progress possible without stalling the foreground process.
  - jacquesm 3y ago
    A kernel compile is not CPU bound.
    - antiframe 3y ago

dijit 3y ago

I would like to stem a little bit of sentiment here. I can write a toy program that saves files to disk much faster than notepad.exe, but this is a consequence of making fewer decisions and handling fewer edge cases. It's trivial to make fast software, especially toy software, but they tend not to survive practical applications without becoming as slow or slower than the systems they originally mimic. That said: that it works is really cool.

rumdz 3y ago

You can swap out the scheduler dynamically using eBPF!? That's incredible.

soulbadguy 3y ago
Yeah, i was surprise to read that. For me that a way bigger deal than the language used...
tuetuopay 3y ago
this blew my mind. all people are arguing whether rust is a good fit, a strike force, or if a game is a good benchmark. the whole point of this is that one guy can write a scheduler during winter break and friggin hot swap it at runtime while a compile and a game can run. this is the newsworthy part. dang it, I want to try it now. and make an article stating I did it in Zig for the clicks!
manifault 3y ago
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 https://github.com/sched-ext/scx. LWN wrote a nice article on this as well a while back: https://lwn.net/Articles/922405/ https://lwn.net/Articles/922405/.

flohofwoe 3y ago

That such a simple 2D game isn't able to reach 60fps under heavy system load just shows that the vanilla scheduler doesn't boost the process associated with the currently active window though? Shouldn't this be standard on all 'desktop' operating systems, e.g. anything associated with the user gets higher priority than anything else happening on the system? Even the Amiga had such a priority-boosting system back in 1985 (otherwise multitasking wouldn't be of much use on such a slow computer, because pretty much any background task would make the UI unusable).

mariusor 3y ago
How would the vanilla scheduler know which process is associated with the currently active window? You're assuming there's more cooperation between the various layers of a linux desktop than I think there really are.
- flohofwoe 3y ago
  One would think that at least a rewrite-from-scratch effort like Wayland would have come up with a solution. Unfortunately the same problem also exists on other systems. Visual Studio even had to add a feature "Run build at low process priority" for the system to remain usable during builds: https://devblogs.microsoft.com/cppblog/msbuild-low-priority-builds-in-visual-studio https://devblogs.microsoft.com/cppblog/msbuild-low-priority-...
  - mariusor 3y ago
    I mean the end-user can always write the glue required to get the current running window get its process and mark that as the "high priority", but that's still working under the constraints of the regular scheduler.
- soulbadguy 3y ago
  The scheduler doesn't need to know which process is associated with the currently active windows. Simple heuristics can get you which to "reasonably" guesstimate which process are interactive and which aren't. For example, every X and descendant, or everything waiting on keyboard/controller or any other input. I think the linux kernel historically did not want to prioritize interactive processes like windows and macos does. The other thing is of course to reduce the CPU quanta, trading latency for throughput. I think most modern distribution do ship with better quanta for smooth GUI/desktop behavior.

amluto 3y ago

> For production scenarios, other schedulers are likely to exhibit better performance, as offloading all scheduling decisions to user-space comes with a certain cost. Aside from possibly increased scheduler latency, there’s the rather larger potential cost of outright deadlocks: what guarantees that the user scheduler task runs at all when it’s needed? On 60 seconds of skimming the repo, I didn’t spot a specific solution to this problem. I wonder how it was addressed. Or maybe it wasn’t, since this is just an experiment.

loeg 3y ago
At least in one version of the documentation patch, there's mention of a watchdog timeout that unloads the user scheduler if it fails to make forward progress for some period of time. https://www.uwsg.indiana.edu/hypermail/linux/kernel/2307.1/02300.html https://www.uwsg.indiana.edu/hypermail/linux/kernel/2307.1/0...
- manifault 3y ago
  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.
manifault 3y ago
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_rustland/src/bpf/main.bpf.c#L450-L468 https://github.com/sched-ext/scx/blob/main/scheds/rust/scx_r...
- amluto 3y ago
  Hah, I should have spent 120 seconds searching :)

DeathArrow 3y ago

Had this scheduler not been written in Rust, would it still have ended up on HN?

RedlineTriad 3y ago
Hard to answer, but I was interested because I assumed it built on the "recent" work to bring rust into the kernel. Where I haven't read much news about how it is being used except for Asahi Linux. Somewhat disappointed that it is using eBPF instead, but still interesting to learn that even such fundamental and performance sensitive parts such as the scheduler can be changed.
ksec 3y ago
If you mean submission to HN then yes because I would have submitted it. If you mean ended up on HN as in front page of HN, then definitely no.

up2isomorphism 3y ago

Highly doubt subpar Linux gaming experience is due to its scheduler implementation.