Announcement

Collapse
No announcement yet.

Rust-Written LAVD Kernel Scheduler Shows Promising Results For Linux Gaming

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • oiaohm
    replied
    Originally posted by waxhead View Post
    I am just curious if the same performance could be achieved with EEVDF and nice -n -10 taskset -c <num> command
    The answer is no. What going on is here making a group bias scheduler.

    Yes the nice command locked the C and told the application to have more preference. This falls apart quickly with a graphical application. Lets say the graphical application gets too much processing time that the wayland compositor/X11 display server or pulseaudio/pipewire or ... something else the graphical application is using now you have tearing/broken audio and so on.

    There is a need to make a group of applications higher priority to get CPU time with even a bias inside that.

    We can also bet that these schedulers will not work right for every game because there is going to be games that have something like some of the heavy anti-cheat system that if you bias against instead of for the game core will run better.

    I do expect to see some custom for game Linux loadable bpf schedulers.

    Leave a comment:


  • ahrs
    replied
    Originally posted by RejectModernity View Post
    Why not implement it in kernel directly? Why do we need these BPF hoops?
    Because BPF allows for rapid prototyping to experiment and prove the scheduler. There's no reason why they couldn't implement it within the kernel directly.

    Leave a comment:


  • dpanter
    replied
    Oh LAVD he coming

    Leave a comment:


  • waxhead
    replied
    I am just curious if the same performance could be achieved with EEVDF and nice -n -10 taskset -c <num> command

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by phor2131 View Post
    Looks like the meat of the scheduler is actually written in C:
    https://github.com/sched-ext/scx/blo...bpf/main.bpf.c
    Yeah, Im a bit curious at why they choose to do the scheduling logic inside of C and no rust, but still use rust for the other bits and bobs, but I haven't played with the code itself so I can't really comment on that other then it feels weird. Rustland showcases a rust solution quite well. and there are all C scheds here too. so it feels a little odd to me personally.

    Leave a comment:


  • Alexmitter
    replied
    Originally posted by uid313 View Post
    I wonder what scheduler Windows have, and I wonder if Microsoft have another scheduler for Xbox or what tweaks to the scheduler they use for Xbox which runs a modified version of Windows.
    Its interesting, the (actual) Xbox OS is practically a single application OS. It was forked of 2000 and heavily modified and to this day it can't really do anything but run a single application but fast. Now you probably wonder how the Xbox 360 and One/Series do run multiple things. Its simple, they run on a different OS.

    The Xbox essentially has two OS's, the specialized OS the games run on and since the Xbox One a user facing OS that is based on the Embedded/Windows Phone/Mobile codebase. They switch between via their hypervisor.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by oleid View Post
    That makes sense, AFAIK there is currently no rust to bpf compiler.
    There have been experiments in it, like RedBPF, but I don't know if any are still active.

    Leave a comment:


  • oleid
    replied
    Originally posted by phor2131 View Post
    Looks like the meat of the scheduler is actually written in C:
    https://github.com/sched-ext/scx/blo...bpf/main.bpf.c
    That makes sense, AFAIK there is currently no rust to bpf compiler. From the readme:

    This scheduler consists of the BPF part and the rust part. The BPF part makes all the scheduling decisions; the rust part loads the BPF code and conducts other chores (e.g., printing sampled scheduling decisions).

    Leave a comment:


  • darkonix
    replied
    Originally posted by EphemeralEft View Post

    Saying that BPF is good because it can't crash the kernel is like saying that Javascript is good because it can't crash the web browser. .
    Agreed. JavaScript should crash the kernel every time it fails.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by EphemeralEft View Post
    I think you misunderstood my analogy. HTML/CSS is like user-space, Javascript is like BPF, and the web engine is like the kernel. Saying that BPF is good because it can't crash the kernel is like saying that Javascript is good because it can't crash the web browser. Ok, but the web engine is literally built to render the web page and if Javascript encounters an error the website is basically unusable anyway. Like BPF, Javascript has its uses (for example, interactive content), but when you build your entire stack on Javascript, your browser has to load 500+ dependencies and 5+MB per page. The redesigned Reddit is a choppy mess on my 2015 laptop, yet the old design is as performant as ever.
    BPF is absolutely not like javascript. You cannot load two BPF schedulers at the same time. Yes BPF has many intentional limitations like this to prevent stacking to hell. BPF you run a userspace program but this then a bytecode is transfered to kernel and validated then converted to binary then run in kernel space.

    BPF is more a safe way to doing a kernel module. BPF does not allow unlimited stupidity like javascript does.

    Leave a comment:

Working...
X