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

  • direc85
    replied
    I just gave a quick 3min spin of LAVD and I am in awe. No more micro stuttering! It's nothing short of amazing!

    Leave a comment:


  • krzyzowiec
    replied
    Originally posted by EphemeralEft
    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.​
    That has nothing to do with JavaScript. Reddit design is simply terrible. You don't need to load many dependencies. A lot of those are trackers and advertising-related code.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ATLief View Post
    Keep in mind that if a CGroup is allocated more resources than its children "need", then those resources are proportionally redistributed to other CGroups; if the graphical session doesn't "need" all of its allocated resources and the graphical application has a much higher priority than all other eligible CGroups, then most of the session's excess resources will automatically be given to the application (and vice versa).

    This you are missing something why this logic cannot work. I said bias distribution is this is not doing it proportionally for reasons.

    Originally posted by ATLief View Post
    I would argue that the scheduler configuration doesn't need to change dynamically because part of its design already includes dynamic redistribution. I'm not saying there's no situation where a custom scheduler could be so much better than existing solutions that it justifies the added complexity, but I think those situations would be extremely rare.
    What cases the problem with games it that you are needing a real-time/dead-line scheduler with quite a bit of complexity to avoid stutters..

    1) The graphical session has just rendered a frame and displayed frame
    vs
    2) graphical session is coming up on time displaying a frame and has not rendered it yet.

    Yes at 1 not giving the graphical session cpu time is not going to cause a graphical stutter. Option 2 you take CPU time away from the graphical session now you get graphical stutter.

    The same as what just happened with the graphical session happens with the game itself that there are times when it less important to be giving the game big slices of processing time.

    ATLief avoiding stuttering when something is given it CPU time just as important as giving the process enough CPU time on average. Of course input lag is another fact that the graphical session has to get so much slices of CPU time to process input to pass to application so that user input is not lagged too much. Of course games need to get processing to process this input as well.

    Game stuttering is a very common case where the general current scheduler designs don't work out. Also the Linux kernel real-time style schedulers are not design to be biasing on changing dead-line.

    What you are describing will get you with games decent over all average performance. Problem is the 1% lows and the 0.01% lows in FPS that are the stutters. These happen even when scheduler is not allocating all the CPU time. This is a problem of the schedulers timing to allocate CPU time.

    The form bias distribution that is required is staving processes of cpu when it will be harmless output even for what you would mark as really high priority so it can be given to a lower priority process because its in key operation stage that if it does not get CPU at this point in time there is going to be graphical or audio or input issue.

    This being the issue that causes the stutter increasing your session priority on many games happens to make 1% and 0.01% lows worse because there are more cases where the game is getting pushed to the back of the que for CPU time behind the session when at that point of time it need to be head of que.

    Making graphical applications like games in fact work well is a very complex scheduler problem needing lot more complex rules. Lot of your real-time devices have simpler scheduler requirements.

    Leave a comment:


  • ATLief
    replied
    Originally posted by oiaohm View Post
    This what in theory seams to work. You find doing this causes worse 1% lows in some games. Stuttering comes from resource starvation somewhere with games. Nice -19 might have the graphical session getting CPU processing time when the game need CPU time to meet a deadline so frame is rendered on time. Now you can have the reverse as well where the game got given time and the graphical session was coming up on a deadline both will cause a graphical stutter. There is audio stutter and so on.
    Keep in mind that if a CGroup is allocated more resources than its children "need", then those resources are proportionally redistributed to other CGroups; if the graphical session doesn't "need" all of its allocated resources and the graphical application has a much higher priority than all other eligible CGroups, then most of the session's excess resources will automatically be given to the application (and vice versa).

    Gets complex quick. Anti-cheat might need higher priority when it sending information up to server so you don't get banned but need to be lower when it not doing that so you don't have stuttering. The CGroups are more designed for server tasks not this problem where scheduler configuration will need to change dynamically.

    Basically you start needing some quite complex rules attempting to fix up 1% and 0.01% lows and not goof something up. Way more than you can do with normal scheduler controls.
    I would argue that the scheduler configuration doesn't need to change dynamically because part of its design already includes dynamic redistribution. I'm not saying there's no situation where a custom scheduler could be so much better than existing solutions that it justifies the added complexity, but I think those situations would be extremely rare.

    Leave a comment:


  • murlakatamenka
    replied
    I've spent some time to find out how to enable those schedulers on a custom kernel (i.e. self-compiled linux-xanmod), and here is the answer:

    This blog post introduces sched_ext, a recently proposed extensible scheduler class. sched_ext allows you to write and run your custom process scheduler optimized for your target workloads and hardware architectures using BPF programs. In the rest of the post, I recap the concept of a scheduler at the high level and go over the default schedulers in Linux kernel. Then, I introduce why an extensible scheduler framework, sched_ext, is necessary, how to use it, and provide a BPF scheduler example.



    Compile the kernel with a patchset from CachyOS:

    - https://github.com/CachyOS/kernel-pa...ched-ext.patch (6.8)
    - https://github.com/CachyOS/kernel-pa...ched-ext.patch (6.9)

    and

    Code:
    # essential configs to enable sched_ext
    CONFIG_BPF=y
    CONFIG_SCHED_CLASS_EXT=y
    CONFIG_BPF_SYSCALL=y
    CONFIG_BPF_JIT=y
    CONFIG_BPF_JIT_ALWAYS_ON=y
    CONFIG_BPF_JIT_DEFAULT_ON=y
    CONFIG_PAHOLE_HAS_BTF_TAG=y
    CONFIG_DEBUG_INFO_BTF=y
    
    # useful debug features for sched_ext
    CONFIG_DEBUG_INFO=y
    CONFIG_SCHED_DEBUG=y
    CONFIG_DEBUG_INFO_DWARF5=y
    CONFIG_DEBUG_INFO_BTF_MODULES=y​
    Then just use scx-scheds from CachyOS. Install the package, edit /etc/default/scx and enable scx.service

    ---

    Or follow the guide that Quackdoc kindly shared earlier:

    Phoronix: Rust-Written LAVD Kernel Scheduler Shows Promising Results For Linux Gaming Changwoo Min with Igalia presented yesterday at Open-Source Summit North America on optimizing the kernel's scheduler for Linux gaming. Of course, the motivation is around Valve's Steam Deck but for Linux gaming at large to benefit too from
    Last edited by murlakatamenka; 27 April 2024, 09:30 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ATLief View Post
    That's a matter of tuning rather than a fundamental limitation of weighted resource distribution. If your graphical session has nice -19 (very high priority) and some graphical application has nice -15 (high priority), then the graphical application will have higher priority than most other processes but never cause the graphical session to lag.
    This what in theory seams to work. You find doing this causes worse 1% lows in some games. Stuttering comes from resource starvation somewhere with games. Nice -19 might have the graphical session getting CPU processing time when the game need CPU time to meet a deadline so frame is rendered on time. Now you can have the reverse as well where the game got given time and the graphical session was coming up on a deadline both will cause a graphical stutter. There is audio stutter and so on.

    Originally posted by ATLief View Post
    To make a game (or any application) with differently-prioritized processes, put them in different CGroups and configure different priorities. In your example, the anti-cheat processes could go in a lower-priority CGroup, and all other processes would go in a higher-priority CGroup. The great thing about this interface is that it works the same way for other resources like disk bandwidth and memory usage.
    Gets complex quick. Anti-cheat might need higher priority when it sending information up to server so you don't get banned but need to be lower when it not doing that so you don't have stuttering. The CGroups are more designed for server tasks not this problem where scheduler configuration will need to change dynamically.

    Basically you start needing some quite complex rules attempting to fix up 1% and 0.01% lows and not goof something up. Way more than you can do with normal scheduler controls.

    Leave a comment:


  • ATLief
    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
    A lot of people seem to be conflating the scheduler with weighted resource distribution. There are definitely some parameters that can't be represented by nice/weight values, but most instances of reducing "lag" while other resource-intensive processes are running could be solved without ever touching the scheduler.

    Leave a comment:


  • ATLief
    replied
    Originally posted by oiaohm View Post
    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.
    That's a matter of tuning rather than a fundamental limitation of weighted resource distribution. If your graphical session has nice -19 (very high priority) and some graphical application has nice -15 (high priority), then the graphical application will have higher priority than most other processes but never cause the graphical session to lag.

    There is a need to make a group of applications higher priority to get CPU time with even a bias inside that.
    This can already be achieved by nesting CGroups; the resources allocated to each CGroup can be arbitrarily divided between its own (child) CGroups.

    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.
    To make a game (or any application) with differently-prioritized processes, put them in different CGroups and configure different priorities. In your example, the anti-cheat processes could go in a lower-priority CGroup, and all other processes would go in a higher-priority CGroup. The great thing about this interface is that it works the same way for other resources like disk bandwidth and memory usage.
    Last edited by ATLief; 19 April 2024, 01:10 PM.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by dpanter View Post
    Oh LAVD he coming


    at least 5 characters

    Leave a comment:


  • oiaohm
    replied
    Originally posted by ahrs View Post
    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.
    There is a reason. This scheduler thing is most likely going to be like bpf for tracing and networking and so. I do suspect different games will need custom bpf schedulers so they work the best. The in kernel scheduler to attempt to be a all round generally ok item.

    The issue with this scheduler biasing as software changes over time different biasing will come required this is where hard coding this into kernel will end up bad. There have been many different in kernel schedulers done to improve graphical user experience that over time all of them biasing method over time has end up wrong for general usage. Yes the bias method at first appeared good. Having to rebuild a kernel to get a new scheduler biasing method also meant these third party schedulders in kernel had very limited uptake.

    The big advantages of this bpf schedulers
    1) Able to use many distribution stock kernels.
    2) Able at runtime fall back to a stock most good enough scheduler if the bias design does not suite in a stable way.
    3) able to release new bpf schedulers and updates to bpf schedulers outside the kernel update time table.(yes kernel.org and the distribution you are using) to alter the scheduler to support newest software out.

    Number 3 to deal with the latest game/program say we need the feature rapid prototyping with biasing scheduler because your general slow kernel development and distribution kernel updates is going to be providing the optimization quite late to lot of the users who want it.

    Do note most of these benchmarks examples show how the FPS of the game has been improve. Question what has to done to building the kernel in background and so on competition time.


    Leave a comment:

Working...
X