Announcement

Collapse
No announcement yet.

The Disappointing Direction Of Linux Performance From 4.16 To 5.4 Kernels

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

  • The Disappointing Direction Of Linux Performance From 4.16 To 5.4 Kernels

    Phoronix: The Disappointing Direction Of Linux Performance From 4.16 To 5.4 Kernels

    With the Linux 5.4 kernel set to be released in the next week or two, here is a look at the performance going back to the days of Linux 5.14 from early 2018. At least the Linux kernel continues picking up many new features as due to security mitigations and other factors the kernel performance continues trending lower.

    http://www.phoronix.com/vr.php?view=28453

  • starshipeleven
    replied
    Originally posted by skeevy420 View Post

    Cylons.
    That's debatable. They wanted to kill everyone

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Azrael5 View Post

    I know. It's hardware flaws. So the question is if free-bugs Cpus are affected by mitigation as well.
    No, mitigations are turned off for those CPUs.
    For example Meltdown mitigation is turned off for AMD CPUs that are not affected.

    Leave a comment:


  • Azrael5
    replied
    Originally posted by pgoetz View Post

    I'm not sure, but who has bug-free CPUs? AFAIK, the Intel vulnerabilities go back years and affect multiple generations of CPUs.
    Some kind of Arm Cpus are free from the known bugs.

    Leave a comment:


  • tytso
    replied
    FWIW, I wasn't able to replicate the performance delta using upstream kernels, running on a Google Compute Engine VM, machtype n1-highcpu-8, using a GCE Local SSD (SCSI-attached) for the first benchmark, which I believe was the pts/sqlite benchmark using a thread count of 1:

    SQLite 3.30.1
    Threads / Copies: 1
    Seconds < Lower Is Better
    5.4.0-rc3 ................. 224 |==========================================
    5.3.0 ..................... 225 |===========================================
    v5.4-rc3-80-gafb2442fa429 . 227 |===========================================
    5.4.0-rc7 ................. 223 |==========================================

    Processor: Intel Xeon (4 Cores / 8 Threads), Chipset: Intel 440FX 82441FX PMC, Memory: 1 x 7373 MB RAM, Disk: 11GB PersistentDisk + 403GB EphemeralDisk, Network: Red Hat Virtio device

    OS: Debian 10, Kernel: 5.4.0-rc3-xfstests (x86_64) 20191113, Compiler: GCC 8.3.0, File-System: ext4, System Layer: KVM

    Leave a comment:


  • skeevy420
    replied
    Originally posted by pgoetz View Post

    I'm not sure, but who has bug-free CPUs? AFAIK, the Intel vulnerabilities go back years and affect multiple generations of CPUs.
    Cylons.

    Leave a comment:


  • pgoetz
    replied
    Originally posted by Azrael5 View Post
    I know. It's hardware flaws. So the question is if free-bugs Cpus are affected by mitigation as well.
    I'm not sure, but who has bug-free CPUs? AFAIK, the Intel vulnerabilities go back years and affect multiple generations of CPUs.

    Leave a comment:


  • pgoetz
    replied
    Originally posted by betam4x View Post
    I am not saying it has been done, but it is most certainly POSSIBLE. That fact alone should give you pause. You folks disabling mitigations and other security features are nuts.

    Hard to exploit vulnerabilities that have been exploited stay private. Quite often, only your data or access to your machine is sold or used fore nefarious purposes, not the vulnerability itself.
    A lot of my systems are
    1. Used for lengthy scientific computations
    2. Behind a firewall
    3. Are only accessible by trusted users, mostly scientists who both know nothing about hacking and don't care
    I can't think of any reason why I wouldn't disable mitigations on these systems.



    Leave a comment:


  • Azrael5
    replied
    Originally posted by pgoetz View Post

    Don't rant: read and understand. The slowdown is largely due to hardware security mitigations, which you can turn off.
    I know. It's hardware flaws. So the question is if free-bugs Cpus are affected by mitigation as well.

    Leave a comment:


  • geearf
    replied
    Originally posted by Paul Frederick View Post

    In case you are unaware Nvidia licenses technology from others. It is not theirs to just give away either. So a binary driver is the absolute best they can do. 70 years beyond the death of an author that may change? Until then Nvidia is bound by copyright law just as much as anyone else is.
    That's a poor excuse, if others GPU companies managed, especially smaller ones like AMD, nVidia could too if it wanted.
    I'd also guess most of these to-hide-technologies would no be in the kernel driver.
    Finding their drivers/hardware better sure, arguing about it all day ok, but I fail to see the point of trying to defend nVidia on the topic of not opening their driver.

    Leave a comment:

Working...
X