Hi,

Assuming the Linux kernel has the correct CPU options compiled in, how efficient is it at utilizing multi-core CPUs? I ask because i read something the other week about how Microsoft are going to have to rewrite most of the Windows kernel to take advantage of future CPUs when they exceed 4 cores.

So currently I am using a 2 core CPU and hopefully soon a 4 core, does the kernel automatically share threads between the 2 cores? Or is it up to the application to delegate thread affinity? And is there going to have to be a major rewrite of the linux kernel to use multicores effectively in the future?

Thanks alot,

Jack

The x86 Linux kernel works "out of the box" with up to 32 CPUs/cores, though the largest supercomputing clusters running Linux run on over 65,535 processors.

I ran Linux on an 8 CPU machine (single image) in 1998. I don't think you'll have any problem.

A multi-core CPU is a simplified version of "a true multi-CPU machine." But the Linux kernel treats it (more or less) the same.

It is your responsibility as an application programmer to specify what your application requires, not to determine how the operating system services those requirements. The operating system's job is to manage the system as efficiently as it can, given the current workload and the nature of the hardware.

Never the twain shall meet.

While applications don't get directly involved in the management of system resources, there are ways in which applications can be structured to allow the OS to better utilize multiple processors/cores.

Large CPU intensive monolithic applications will see little benefit from SMP. While multiple such applications can be scheduled and dispatched concurrently by the OS, each application is limited to the processing resources of a single CPU. This is less of a concern for advanced users that naturally have a high multitasking behavior. For example, transcoding several videos/mp3s in the background, while running multiple concurrent file transfers.

By forking sub-processes or using threads, a single application can be scheduled/dispatched by the OS to span multiple CPUs. The tricky thing about this is that such an application structure has an overhead that a monolithic structure does not (i.e., it's less efficient). This means that on a system with a single CPU, the application will have a lower throughput than a monolithic equivalent. Some applications (e.g., make) allow you to manually specify a level of concurrency, reconfiguring the structure at runtime. Doing this increases complexity for the user, obviously.

This is really only a transitional issue. SMP, with the introduction of multi-core chips, is becoming the norm. As a result, all applications should be structured to break large monolithic segments into threads/subprocesses going forward. The end result for the user is that, with no intervention, processing intensive activities will fully exploit multiple CPUs.