Unlock the Power of Linux on SMP Systems

Running Unstable, I noticed last summer that new kernels were being put out with SMP enabled by default.

There had for a long time been parallel kernels with SMP turned on, but the separate SMP kernels went away and the default ones started showing up with SMP enabled.

I doubt it's much overhead if any, and with the onrush of dual-core and, Cromm willing, quad-core, systems as the default, I guess it's a perfectly good policy.

Hopefully, gcc and the other "standard" compilers will have SMP optimizations optimized. If I were anything of a programmer, spending some time hand tuning gcc, glibc and such, would be what I would want to do. Make an application faster, fine. Make the library/compiler more efficient, then _every_ application gets a boost even though it's less glamorous.

Would that be the "civil engineering" of programming?

> Hopefully, gcc and the other "standard" compilers will have SMP optimizations optimized.

Not really sure what you mean, do you mean have gcc be able to make SMP-aware optimizations?

To have the compiler optimize for multiple cores, you can't really do it effectively with C/C++ - it's just fundamentally impossible. You need a language with pervasive data dependency tracking and for programmers to write code that avoids criss-crossing dependencies and provides scheduling hints on branches.

Ah. Now you see why I never pretend to be a programmer.

Quoting:Running Unstable, I noticed last summer that new kernels were being put out with SMP enabled by default.

IIRC that's actually thanks to a feature that went into the 2.6.16 or 2.6.18 kernel that can detect at run-time (boot I think) wether it's running on SMP hardware or not.

"kernel that can detect at run-time (boot I think) wether it's running on an SMP kernel or not."

I think you mean detect whether or not it's running on SMP _hardware_.

But it still shows up as an SMP kernel, and my system is not.

$ uname -a Linux bob 2.6.18-4-686 #1 SMP Wed Feb 21 16:06:54 UTC 2007 i686 GNU/Linux

Yes, I meant hardware. I've corrected it.

i686? Then you probably have a CPU with Hyper Threading (What is AMD's equivalent?). That qualifies as SMP I believe.

Nope, I don't know about Bob's, but, mine definately is incapable of hyperthreading.

Linux jimf 2.6.20-1-686 #1 SMP Sat Mar 17 00:56:31 UTC 2007 i686 GNU/Linux

If you do have 2 cpu, or dual core it would say '#2 SMP'.

Ah well, I don't know then. All computers I have running at the moment are SMP capable so I can't check. Perhaps it's just an indication that the kernel is SMP capable and not if it's actually enabled SMP? Surely there is some way to check for that. What does /var/log/dmesg say about SMP?

> Perhaps it's just an indication that the kernel is SMP capable and not if it's actually enabled SMP?

That's what Bob and I are saying. Debian 'has' made the decision to eliminate a separate SMP kernel and have all their 2.6.xx kernels be SMP capable. I assume this is because SMP has become so common via the dual cores. As for mine, no need to check, It won't even hyper thread.

Well, it shouln't matter anyway with the 2.6.18 kernels. SMP is disabled at boot time so the "SMP capable kernel" that you run should just be as fast as a non-SMP kernel would be.

Ah, I found the LWN article about it: http://lwn.net/Articles/164121/

It's called SMP alternatives and it's used to switch between SMP and non-SMP at run-time, even allowing for hot-plugging CPU's and all that.

> If you do have 2 cpu, or dual core it would say '#2 SMP'.

No. The 'number' is a type of compiler iteration, if I recall correctly.

> What is AMD's equivalent?

AMD had no equivalent of HT that I am aware of: They beat Intel at x86-compat 64-bit, instead.

> IIRC that's actually thanks to a feature that went into the 2.6.16 or 2.6.18 kernel that can detect at run-time (boot I think) wether it's running on SMP hardware or not.

Correct. It was .16, or possibly earlier than that for Debian. (Note that on release of .22 we can start referring to the kernel's "caliber".)

What I wish to point out: Red Hat has gone this direction recently too. Because of earlier kernel strategies it can get wildly confusing at the high end to upgrade. But at the basic level, current FC6 and RHEL5 kernels are SMP/detecting style kernels like Debian.

> The 'number' is a type of compiler iteration, if I recall correctly.

Could be, I don't have Debian on my only dual cpu rig. Just taking a guess.

Quoting:What is AMD's equivalent?

AMD did not do a type of hyper threading in their processors because they have a fairly short pipeline (12 stages) compared to the pentium 4s 31. When there are empty stages in the pipeline then the cycle is wasted. So Intel virtually split the pipeline into 2 shorter ones that allowed for a sudo-multiprocessor with only one core, and called it hyperthreading. AMD didn't need to do this since they already had a small efficient pipeline.

This is one of the main reasons why a 2ghz Athlon is comparable to a 3+ghz pentium 4..

"AMD didn't need to do this since they already had a small efficient pipeline."

The Motorola pipeline is/was even shorter, which was utilized in a very effective Apple campaign called "The MegaHertz Myth", when trying to tell people how a Mac, with a "slower" CPU, outperformed Windows machines with the long Intel pipelines.

Now that Macs are using Intel CPUs, that particular bit of leverage goes out the window.

If I could snap my fingers and have any system I wanted, I'd take a 4-socket NUMA motherboard with dual-or quad-core AMD CPUs. But I am so freaking far away from actually utilizing anything like that much power it's absurd.

If I were doing video transcoding every day, maybe.

It sure would help my ranking on distributed.net!