Improving Linux Kernel Performance

developerWorks writes "The first step in improving Linux performance is quantifying it, but how exactly do you quantify performance for Linux or for comparable systems? In this article, members of the IBM Linux Technology Center share their expertise as they describe how they ran several benchmark tests on the Linux 2.4 and 2.5 kernels late last year. The benchmarks provide coverage for a diverse set of workloads, including Web serving, database, and file serving. In addition, we show the various components of the kernel (disk I/O subsystem, for example) that are stressed by each benchmark."

Comments

Re:Actually finding the performance problem?

[Chatz]

That's probably a bit harsh, both IBM and SGI have worked pretty hard to get scalability improvements into the linux kernel. The article does mention some of these things:

Some of the issues we have addressed that have resulted in improvements include adding O(1) scheduler, SMP scalable timer, tunable priority preemption and soft affinity kernel patches.

Re:Huh?

[Chatz]

Which you need to know before interpreting the results...

I have to disagree, I thought Figure 3 illustrated how important it is to baseline to ensure that you are heading in the right direction with each change you make (although they did not have a uni-processor baseline result).

It also showed that with the changes in June they are able to get a 4 times performance with another 7 cpus. Maybe next time they will show how it scales over the number of cpus you have.

For simplicity's sake

[r6144]

When running with multiple CPU's, the kernel instances running on these CPUs need regulation when they access shared data. Such regulation is usually implemented with locks. A simple approach is to use a small number of "big" locks (like a lock that makes sure that only one CPU can run actual kernel code). This is very simple and easy to debug, but may cause poor performance because one CPU cannot (for example) do network transfers while another is reading disk, while this should be allowed in principle. So we should use finer-grained locks. However, as we make locks more and more fine-grained, we have more and more locks, so things get messy, hard to debug, and locking/unlocking overhead goes up to make performance degrade for fewer-cpu machines. Because of such a cost, we should make locks finer-grained when it actually improve performance much according to benchmarks.

Of course this applies to something else, like making transfers zero-copy, too.

Re:More attention to IO needed

[g4dget]

In particular I'm interested in how the Linux kernel is designed to handle multiple independent I/O buses.

By running multiple kernels. Seriously: the way to get great performance out of PC hardware is to buy lots of it and cluster it. You still end up paying less for more performance than with the high end systems.

Re:More attention to IO needed

[virtual_mps]

The problem is that the typical PC hardware is just not designed for that. Large proprietary Unix or mainframe systems usually have multiple very high speed buses; a single 32-bit PCI bus is rather low-end in comparison.

A single 32 bit PCI bus is anemic these days. That's why high-end servers based on ia32 processors include multiple PCI busses, increasingly PCI-X (133MHz, 64bit). Note that servers based on other processors are increasingly moving away from proprietary busses and using the same PCI you'll find in those intel-based systems.

Re:The Problems with Benchmarking like this...

[nicodaemos]

Hmmm .... tpc.org is an interesting organization. It is a non-profit who is funded by memberships from the hardware/software companies on which it produces benchmarks.

According to their website, "Full Members of the TPC participate in all aspects of the TPC's work, including development of benchmark standards and setting strategic direction. Full Membership costs $15,000 per calendar year."

Wow, a large percentage of the benchmarks are using MS operating systems. Oh look full members get to set benchmark standards. Mmmm, the only pure OS company who is a full member is Microsoft. I wonder what kind of conclusion can be drawn .......