Announcement

Collapse
No announcement yet.

Linux 5.4 vs. Liquorix Kernel Benchmarks For AMD Ryzen + Radeon Gaming On Ubuntu

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

  • Linux 5.4 vs. Liquorix Kernel Benchmarks For AMD Ryzen + Radeon Gaming On Ubuntu

    Phoronix: Linux 5.4 vs. Liquorix Kernel Benchmarks For AMD Ryzen + Radeon Gaming On Ubuntu

    The Liquorix kernel is the long-standing effort for providing a "better distro kernel" optimized for desktop/multimedia/gaming workloads. As it's been a while since last testing the Liquorix kernel spin of Linux, I recently carried out some tests of its Linux 5.4 based kernel compared to Ubuntu's generic mainline PPA images of Linux 5.4 as well as the low-latency kernel variety.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It's a shame there isn't good tooling on linux for 95th-percentile frame-time style benchmarking, as that would probably be a much better way to tease out the differences between the different scheduling algorithms than bulk fps averages.

    Comment


    • #3
      I thought that was the whole point of mesa's osd... I'm pretty sure it knows what those values are.... a bash script and sed would do it.
      Last edited by duby229; 04 January 2020, 12:43 PM.

      Comment


      • #4
        You need to do latency benchmarks to see improvement over standard kernel.
        Low-latency kernels were always known to offer worse performance at the price of.. lower latency!

        Comment


        • #5
          Originally posted by Yalok View Post
          You need to do latency benchmarks to see improvement over standard kernel.
          Low-latency kernels were always known to offer worse performance at the price of.. lower latency!
          Take a look at total frame time then. CFS low latency is just awesome except if you're some awkward Google 'developer'.

          Comment


          • #6
            Typo:

            Originally posted by phoronix View Post
            lower with the Liquprix kernel...

            Comment


            • #7
              From my own testing with Company of Heros 2, with a low-latency kernel, aggressive compiler flags and the BMQ scheduler, it could also improve performance (in total roughly 10 % above stock).

              Comment


              • #8
                Originally posted by Volta View Post

                Take a look at total frame time then. CFS low latency is just awesome except if you're some awkward Google 'developer'.
                The problem the the 'total' frame time graph is that it masks the relative quantities of low-frame times and high frame times. Real-time applications show perceived 'smoothness' not from really low latency (which does help!) but from really consistent latency. Game consoles get away with relatively lower frame rates because they invest more in frame-time consistency. VoIP applications can get away with relatively high levels of latency if the jitter is really low.

                That's what 95th (98th, 99th) percentile frame-time measurements can show that the total frame-time graphs just don't show.

                Comment


                • #9
                  >not compiling your minimal kernel with a patch for enable GCC optimizations for additional CPUs, BMQ schedule patch, fsync patch and some clear linux patchs
                  Last edited by Mario Junior; 04 January 2020, 02:56 PM.

                  Comment


                  • #10
                    Originally posted by Mario Junior View Post
                    >not compiling your minimal kernel with a patch for enable GCC optimizations for additional CPUs, PDS-mq schedule patch, fsync patch and some clear linux patchs
                    Aye aye! I have a few more I use, but yes these are musts.

                    Code:
                    #https://github.com/graysky2/kernel_gcc_patch
                    echo "*** Copying and applying graysky's GCC 9 tweaks.. ✓"
                    if [ "${KERNEL_BASE_VER}" = "5.4" ]; then
                        cp $PATCH_PATH/graysky-gcc9-5.4.patch .;
                        patch -p1 < ./graysky-gcc9-5.4.patch;
                    else
                        cp $PATCH_PATH/graysky-gcc9-5.5+.patch .;
                        patch -p1 < ./graysky-gcc9-5.5+.patch;
                    fi
                    
                    #https://github.com/sirlucjan/kernel-patches/blob/master/5.4/cpu-patches
                    #https://github.com/sirlucjan/kernel-patches/blob/master/5.4/cpu-patches-sep
                    echo "*** Copying and applying O3 patches.. ✓"
                    cp $PATCH_PATH/0001-cpu-patches.patch .;
                    patch -p1 < ./0001-cpu-patches.patch;
                    
                    #https://github.com/sirlucjan/kernel-patches/tree/master/5.4/futex-patches-v2 (single patch includes everything)
                    #https://lkml.org/lkml/2019/7/30/1398 and https://lkml.org/lkml/2019/7/30/1399
                    #https://gitlab.collabora.com/krisman/linux/commit/368eb7d8c86bd2a5db200567e82c477efc1a9502
                    echo "*** Copying and applying Valve fsync/futex v2 patches.. ✓"
                    cp $PATCH_PATH/0001-futex-Add-support-for-multiple-keys-at-the-same-time.patch .;
                    patch -p1 < ./0001-futex-Add-support-for-multiple-keys-at-the-same-time.patch;
                    
                    #https://github.com/sirlucjan/kernel-patches/tree/master/5.4/clearlinux-patches-v6
                    #https://github.com/sirlucjan/kernel-patches/tree/master/5.4/clearlinux-patches-v6-sep
                    echo "*** Copying and applying Clear Linux patches.. ✓"
                    cp $PATCH_PATH/clearlinux-patches-v6/0001-clearlinux-patches.patch .;
                    patch -p1 < ./0001-clearlinux-patches.patch;
                    
                    #https://github.com/sirlucjan/kernel-patches/tree/master/5.4/bfq-patches
                    #https://github.com/sirlucjan/kernel-patches/tree/master/5.4/bfq-patches-sep
                    echo "*** Copying and applying BFQ patches.. ✓"
                    cp $PATCH_PATH/bfq/$KERNEL_BASE_VER/0001-blkcg-Make-bfq-disable-iocost-when-enabled.patch .;
                    cp $PATCH_PATH/bfq/$KERNEL_BASE_VER/0002-block-bfq-present-a-double-cgroups-interface.patch .;
                    cp $PATCH_PATH/bfq/$KERNEL_BASE_VER/0003-block-bfq-Skip-tracing-hooks-if-possible.patch .;
                    patch -p1 < ./0001-blkcg-Make-bfq-disable-iocost-when-enabled.patch;
                    patch -p1 < ./0002-block-bfq-present-a-double-cgroups-interface.patch;
                    patch -p1 < ./0003-block-bfq-Skip-tracing-hooks-if-possible.patch;
                    (big shout out to sirlucjan for his excellent github repository and maintaining the patches!)

                    *EDIT 01/15/20: I removed the BMQ patches from above. After testing, I don't think it's a "must" and I underrated how well the default CFS scheduler behaved when it was under heaving load (i.e. compiling the kernel and continuing to use the desktop). BMQ was noticeably laggier/slower and was very obvious that something was compiling in the background (make -j4 on 4c/4t Haswell).

                    The following kernel settings have worked best for me, and the benchmarks consistently show it as well: CFS scheduler, tickless idle, 1000 Hz Timer, and Low-Latency Preemptive Kernel.

                    On CFS, there is practically zero slowdown while using the desktop as the kernel is compiling (great work Ingo Molnar and co!). So, while BMQ may behave better with gaming (and jury is still out on that) at the time of this writing, it was not worth it for me to give up CFS for other use cases.

                    Moving forward, I rather not deviate from such a core kernel feature like the CFS scheduler to an out-of-tree scheduler. Nothing against the hard work Con Kolivas, Alfred Chen, etc are doing and I think it's necessary, but I think for my Haswell system, I'm sticking with CFS.

                    As an aside- here are also the patches for CONFIG_PREEMPT_RT which I recently starting experimenting with. I found the results to be good, but it ultimately led to some system stability (because of all the different pieces involved, not necessarily because of the -rt patchset). There's also a bug in VirtualBox with spinlocks that causes it not to work with Windows 10 with the -rt patchset. However, for gaming and real-time low latency use cases, you should definitely give it a shot. Xanmod kernel can provide a -rt kernel if you're looking for something without compiling your own.

                    #https://rt.wiki.kernel.org/index.php...EEMPT_RT_Patch
                    #https://mirrors.edge.kernel.org/pub/...ojects/rt/5.4/
                    #Be sure to turn on in the menuconfig: CONFIG_PREEMPT_RT=y if using this
                    echo "*** Copying and applying CONFIG_PREEMPT_RT patches.. ✓"
                    cp $PATCH_PATH/patch-5.4.10-rt5.patch .;
                    patch -p1 < ./patch-5.4.10-rt5.patch;

                    tl;dr I'd personally avoid the BMQ/MuQSS scheduler patches for now and stick with the (very good) default stock CFS scheduler.

                    *END EDIT
                    Last edited by perpetually high; 15 January 2020, 08:32 PM.

                    Comment

                    Working...
                    X