Slashdot Mirror

← Back to Stories (view on slashdot.org)

Stress-Testing The Linux Kernel

Posted by timothy on from the bully-it-and-ask-embarrassing-questions dept.

An anonymous reader writes "Automating software testing allows you to run the same tests over a period of time, ensuring that you are really comparing apples to apples and oranges to oranges. In this article, Linux Test Project team members share their methodology and rationale, as well as the scripts and tools they use to stress-test the Linux kernel."

9 comments

  1. other area testing by colinleroy · · Score: 4, Interesting
    The tests covered in the article don't cover other user-related stuff in the kernel. One day, when i'll have enough motivation, i'll write a small script testing :
    • video (3D)
    • sound (alsa, oss-emulation)
    • third-party modules state (like linux-wlan-ng)
    • usb printer
    • usb key
    • usb modem
    • ...
    Too many times I missed a problem after a kernel upgrade, and lost time wondering "when did it stop working". I seem to always forget to test the broken thing each time I upgrade ;-)
    --
    blah
    1. Re:other area testing by arodland · · Score: 3, Informative

      Raw 3D performance really has nothing to do with the kernel; if something in the kernel is acting as a bottleneck to 3D performance, it would show up in other places, too. That said, a suitable 3D test on a fast card might serve as a test of really fast IO. But so would 10GigE ;)

    2. Re:other area testing by colinleroy · · Score: 2, Informative

      Well, I put that in my list because, as much as it doesn't seem kernel-related, there has been a bug in one of the last DRM merge in the kernel, causing AGP access by X to fail (and thus falling back to PCI mode). This slowed glxgears by a factor of four on my laptop...
      The bug was due to some 2.4 related code not being stripped when merged in the 2.6 kernel, but the #ifdef guardian itself had been stripped. See this changeset.

      --
      blah
  2. This is how... by Anonymous Coward · · Score: 4, Funny

    it's REALLY done

  3. Stress testing. by BrookHarty · · Score: 3, Informative

    We use all types of telco hardware running private OS's in a production enviroment. We patch on a regular basis, because there is no way to load test this hardware. Enabling new functionality or modifing the enviroment pops up new problems, new software upgrades on connected resources can spring up new problems on a daily basis.

    Its amazing, its like whack a mole, it never gets stable. You spend your time fixing one problem to move onto a new one that pops up with some new feature or alteration becomes production.

    Linux wants to be the OS of choice for production enviroments, 5 nine hardware for critical applications need some kind of testing.

    Don't think of a webserver, think of a dozen servers talking multiple protocols to each other over multiple mediums all changing the data in realtime. Its easy for memory leaks, timing issues, or corruption to appear.

    I guess its good to be a vendor, since the customer will have to pay support contracts to the end of time.

    This is why I laugh at IBM's "Servers are self healing" commericals, while its nice in theory, they make too much money off contracts.

  4. Stress testing by Anonymous Coward · · Score: 4, Informative

    Stress testing is a complicated subject. For basic system stress you can use stress, but often you want more specific tools like siege or mysqlstress. None of them can precisely replicate the exact stress patterns that trigger bugs in real-world Linux deployments. What is needed is a tool that can capture system calls and "play them back" exactly as they occurred.

    1. Re:Stress testing by flok · · Score: 2, Interesting

      Not only that: also the timing, the memory layout, etc.

      --

      www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi