1 / 29

The Linux Benchmark Project

The Linux Benchmark Project. Randy Appleton Kurt Payne Joe Schmeltzer Carey Stortz http://cs.nmu.edu/~benchmark. What We Did. We are three undergraduates and a professor. Measured the source code of the kernel several ways. Measured the performance of the kernel several ways.

vlora
Télécharger la présentation

The Linux Benchmark Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Linux Benchmark Project Randy Appleton Kurt Payne Joe Schmeltzer Carey Stortz http://cs.nmu.edu/~benchmark

  2. What We Did • We are three undergraduates and a professor. • Measured the source code of the kernel several ways. • Measured the performance of the kernel several ways. • This is undergraduate research, yet useful research.

  3. Limitations • We are kernel level only. • We can describe, but only guess at why.

  4. Why Linux? • Linux is important. • The source code is available. • The development process is open. • Early versions available. • Lots of versions available. • Linux is cool!

  5. Which Kernels • All kernels from 2.0.1 to 2.4.0. • About 4.5 years of kernels. • Taken every three months. • Intervals are by time, not version count. • Ordered by version number. • Could have ordered by date. • Justifiable, but not obvious.

  6. Counting Lines • Counted • All lines • Lines with semicolons or braces • Bytes • All the graphs look the same. • Exponential growth at 26% per year. • Overall, 319% growth from 2.0.0 to 2.4.0.

  7. Line Count

  8. Comparing Sizesfrom http://www.dwheeler.com/sloc/redhat71-v1/redhat71sloc.html

  9. Distribution of Lines Version 2.0.1

  10. Distribution of LinesVersion 2.4.0-pre9

  11. Distribution of Lines Over Time

  12. Measuring Performance • We used lmbench. • Ran at least 5 trials. • Averaged the data • Excluding top and bottom value • Excluding any obvious outliers

  13. Null Call Performance • All system calls use the same mechanism to begin and end. • If these mechanisms are slow, then the kernel will always be slow. • This measures the overhead for all system calls. • The measures the performance of very simple system calls.

  14. Null Call Graph

  15. Stat Performance • Stat is the system call that returns file metadata. • Stat is very common. Almost all file system oriented tasks will use stat. • Stat speed is determined by the speed of the file system and the directory cache. • This data is a combination, with lots of caching.

  16. Page Fault Performance • A Page fault occurs when the system needs to bring a VM page into RAM. • Hard page faults go to disk, and speed is determined by disk speed. • Soft page faults recover the page from some other part of RAM, and the speed is determined by the kernel and MMU hardware.

  17. Mmap performance • Mmap is used to alter the memory map of a process. • Mmap is fundemental to how programs using shared libraries begin. • Mmap is also used to establish a shared memory region between communicating processes.

  18. Context Switching Performance • This test uses rings of processes communicating via read/write. • Simulates many situations in real life • Processes communicating with the X server. • Commands using pipes. • This is not a networking test!

  19. Signal handling Performance • This measures the time needed to switch processes due to software interrupt. • This is a stand-in for measuring the hardware interrupt switch time. • Hardware interrupt time is critical for all high speed data throughput.

  20. Signal Handling Analysis On Thu, 26 Apr 2001, Linus Torvalds wrote:>I'll take a look at what the signal handling thing >is, although I suspect it's just the cleanup for >eventually getting thread-safe signals and> pthreads semantics..That might be a small part of it, but from initial profiles it appears that the biggest chunk of it by far is just the new floating point format for supporting the full SSE information…

  21. Performance Conclusions • Linux is generally getting faster. • Extra lines of code are not slowing Linux down. • Sometimes, algorithm changes cause a >10x speed improvement. • No one knows for a user-level workload. • There is no easy record of algorithm changes for Linux.

  22. Being Slashdot-ed • The research looked interesting. • I want to maximize the experience for my students. • I submit to slashdot.http://www.slashdot.org • They accept!

  23. Slashdot-ed, the day after • Saw 122,089 hits from 42,645 unique IPs. • 99 different nations, including 39 Belarus (39) Luxembourg (39), Iceland (76). • The UK had 2,264 hits. • Intro translated into French, Spanish, German, Russian, Slovak, Italian. • Students absolutely loved it. • Received over 300 emails (not all nice).

  24. Encouragement • Research is fun! • Research doesn’t need a national lab. • Small efforts can also help.

More Related