Announcement

Collapse
No announcement yet.

Five Years Of Linux Kernel Benchmarks: 2.6.12 Through 2.6.37

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

  • TemplarGR
    replied
    Originally posted by michal View Post
    I'm aware of that. That's true for X.org drivers, syscall support in glibc and other things.

    But let's face the truth - you can not compare apples to oranges. If you want to compare kernel speed, you need to change only kernel. That was true 20 years ago, 10 years ago, when I played this stuff and it's still true now.

    What are you talking about is speed of the whole OS. And you are right - for such benchmark all things should be updated for appropriate version numbers. But AFAIU this benchmark intend to measure only kernel speed.
    If you really want to test only kernel speed, then you shouldn't use a regular GUI distribution anyway. You would need another testing environment. Stripped of almost all non-essential stuff.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Originally posted by V!NCENT View Post
    All I see is abstraction. The Linux kernel has many, many appliances. But I have no idea what I'm talking about...

    But you can still learn something

    In fact, I always learn something new every day

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Originally posted by TemplarGR View Post
    A large part of kernel functionality is accessed using userspace libraries. If those libraries are old, some features cannot be used or you lose some improvements of later versions.
    I'm aware of that. That's true for X.org drivers, syscall support in glibc and other things.

    But let's face the truth - you can not compare apples to oranges. If you want to compare kernel speed, you need to change only kernel. That was true 20 years ago, 10 years ago, when I played this stuff and it's still true now.

    What are you talking about is speed of the whole OS. And you are right - for such benchmark all things should be updated for appropriate version numbers. But AFAIU this benchmark intend to measure only kernel speed.

    Leave a comment:


  • Veerappan
    replied
    Originally posted by V!NCENT View Post
    I don't care if you test it on Windows or Plan9. You have the base performance of a vitual machine implementation where there is no chance of direct HW tricks. Why is that not perfect? But no... let's check for HW specific optimisation drivers that can peak performance in area's that have nothing to do with the kernel itself but with a specific implementation that's not representative of all tge hardware that Linux can run with...
    This is incorrect. Optimizations to the drivers used in the VM itself can still affect the performance of the virtual machine being tested. Optimizations made to the drivers used in the VM are no different than optimizations made in the drivers for physical hardware.

    The problem with testing on a virtual machine is that you now have to worry about bottlenecks in the host, activity on the host machine affecting the performance on the guest VM, and quirks of the VM software (such as VirtualBox not respecting fsync() as we learned in several Phoronix filesystem articles).

    That being said, it's still nice to see these benchmarks. They may be affected by the host VM software, but they have taught me that 2.6.29 was very likely a crappy kernel release.

    Leave a comment:


  • V!NCENT
    replied
    All I see is abstraction. The Linux kernel has many, many appliances. But I have no idea what I'm talking about...

    I don't care if you test it on Windows or Plan9. You have the base performance of a vitual machine implementation where there is no chance of direct HW tricks. Why is that not perfect? But no... let's check for HW specific optimisation drivers that can peak performance in area's that have nothing to do with the kernel itself but with a specific implementation that's not representative of all tge hardware that Linux can run with...

    Don't pay attention to the retard that questions the established theory...

    Leave a comment:


  • TemplarGR
    replied
    Originally posted by V!NCENT View Post
    So what? It was benchmarket in a thread... That's hella better than doing it on real hardware where performance may be hindered by driver implementations...

    A thread runs consistant. Again... the problem? Multithreading? Errr... boohoo!
    Again you do not seem to know what you are talking about(as usual).

    If that was the case, why not just use Windows as a host and Linux only as guest? After all, most driver implementations (for pc systems) are more complete and/or fast on Windows...

    In reality, when you benchmark a virtual machine, you largely benchamark the virtual machine implementation and its host performance. That is why in most of these tests performance is similar for all versions of the kernel. Just have a look at the graphs again...

    What is funny is that from what i recall, older kernel benchmarks here on Phoronix revealed larger variations on a nearer range of kernel versions, when performed on native hardware...

    I propose adding a page on this article, testing a native 2005 era machine using Fedora Core 4 with its stock kernel, and later compiling a recent kernel. I believe it will prove my point...

    Leave a comment:


  • TemplarGR
    replied
    Originally posted by michal View Post
    No. Not in _kernel_ test.

    If you want to test kernel, you should not change userspace at all.

    It's difficult, because old kernels doesn't build on modern systems - you even may not be able to boot 2.6.27 (still supported) on latest distros.
    A large part of kernel functionality is accessed using userspace libraries. If those libraries are old, some features cannot be used or you lose some improvements of later versions.

    Leave a comment:


  • V!NCENT
    replied
    Originally posted by michal View Post
    Just read about kernel benchmarks methodologies.
    I genuinly wanted to do that, but I could not find one that could also work on watches, TiVo, TomTom, 386, Android and elevators. Must be because they can't possibly do virtualization even though they are all running the Linux kernel...

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Originally posted by V!NCENT View Post
    You test the kernel for global regressions and you not the performance of HW configuration X.

    Or was this not about regression testing? Care to explain why my post was meaningless? Because if it's not then yours is.
    Just read about kernel benchmarks methodologies.

    Leave a comment:


  • V!NCENT
    replied
    You test the kernel for global regressions and you not the performance of HW configuration X.

    Or was this not about regression testing? Care to explain why my post was meaningless? Because if it's not then yours is.

    Leave a comment:

Working...
X