It’s the worst nightmare of every system administrator: a well-working server with a perfect track record gets a security upgrade of the kernel and suddenly the performance drops and the machine can’t handle the workload anymore.
The rate of change in the Linux kernel is really high: Greg Kroah-Hartman recently showed that each hour, 4 patches are applied to the Linux kernel, 24 hours a day, 365 days a year. A few million lines of code change every kernel release. Yet despite this high rate of change, the nightmare scenario mentioned above isn’t very likely.
This article shines some light on the issues, projects, and techniques that characterize kernel performance — ensuring system administrators around the world can sleep well at night.
Benchmarks and Performance Testing
Testing performance may sound easy, but in reality, it’s a really tricky and complex topic that requires a lot of skill, great attention to detail, and mounds of patience. Anyone can Google for a Linux benchmark and get two and a half million hits. Anyone can pick a top result, run the program, see the same or a higher number as the day before, declare victory, and ship the patch to Linus with a “this patch is perfect” comment, right? Sadly, things aren’t so easy.
Picking and running a useful benchmark actually requires some thought and investigation. A few things are very important when picking a benchmark, and they may sound obvious, but sadly many of the results you found on Google fail to…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
