SMP vs non-SMP Kernel on an Opteron

[shad0w]

Does anyone know if any issues from running a non-SMP kernel (2.4.21) vs a SMP kernel (2.4.21-27) on an Opteron dual core processor?

Thanks!

[mrrangerman43]

I'm no expert, but if you run the non-SMP you'll only be using one processor chip, or only half the cpu. Is there a reason why you wouldn't want to use the SMP kernel? I have a dual pIII 750, it works fine with the non-SMP kernel, slow, but fine. But it works far better with the SMP-kernel still slow (its a pIII ya know) but better than with out. But as far as I know I haven't read anything saying there is/was a problem.

You may jump over to kernel.org and see if they list any problems.

[happybunny]

i use smp on my AMD 64 dual core just fine....does that answer your question

[shad0w]

The issue is we have 2 types of hardware, the old... and the new...

We have 600 servers out in the field, but all of them are single proc. Our vendor is no longer selling single proc systems, and we are being forced to move to dual Opterons.

Our enviroment is such that we require all servers to be uniform on all software installed.

That being said, I can either upgrade all machines in the field to SMP (on the 2.4 kernel) or I can keep the exiting single cpu kernel (2.4).

Which one is less likely to have problems (crashing and/or performance).

The single procs are intel and opterons.

[Crito]

Moving to 2.6 would cause the least problems, as you no longer have to worry about SMP or non-SMP kernels. But if you have to stick with 2.4 then I guess you'll also have to stick with a non-SMP kernel and waste half the computing power in your new boxes.

[bwkaz]

Nah, you can run an SMP kernel on a single CPU. That's what I did for quite a long time, while my sound card was causing NMI problems and hard lockups -- I ran an SMP kernel (dual-core CPU), but told the kernel "maxcpus=1", so it ran as a single-processor box. (Finally I found out that it was the sound card, and removed it -- now I run without the maxcpus limit all the time.)

So it works just fine to run an SMP kernel on a single-processor system. Or at least, it did for me (but that was 2.6.19.x-2.6.21.x, not 2.4).

Maybe we should be asking this question, though -- is there a reason you're using a kernel from June 2003? That's well over four years old now; nobody should still be using that. I don't know how many local root exploits exist in that version; there are probably even a couple remote DoS/crash type exploits (e.g. in netfilter). Not a good idea!

[Crito]

I forget when the change was made exactly, but all current 2.6 kernels are SMP enabled and run on single core CPU without any kernel parms.

[Crito]

Gerd's SMP alternatives patch was merged in 2.6.17.

[shad0w]

we can't move to 2.6 (I want to, but we can't), it requires too much test lab time.

Thanks for your help.

[bwkaz]

Gerd's SMP alternatives patch was merged in 2.6.17.

Then why does CONFIG_SMP still exist in 2.6.21.3?

"SMP alternatives" does not force SMP to be on. All it does is allow a distro kernel to enable SMP, and then patch (most of) the SMP-specific assembly out of the kernel at runtime if there's only one CPU. You can still configure your kernel for UP (and you can still turn off the alternatives code if you configure it for SMP). It's a setting for distros, to make their kernels more generic; it's not a setting forced on everyone.

So no, it's not true that "all recent 2.6 kernels are SMP". It is true that recent 2.6 kernels that were compiled for SMP, and also had the alternatives stuff turned on, can re-optimize themselves for UP if needed. But that's a rather different statement.

(Also note that with the alternatives code enabled, there's still some cost on a UP system compared to a kernel that was built for UP -- the lock prefixes turn into NOPs, so they still take up code-cache bytes, for instance. It's a NOP instruction, so it doesn't take more than one clock cycle, but the cache usage is a bigger issue. With a CONFIG_SMP=n kernel, there is neither a lock prefix, nor a NOP; that byte just isn't used. That's why I'm guessing that the CONFIG_SMP setting won't ever go away.)

we can't move to 2.6 (I want to, but we can't), it requires too much test lab time.

Can you at least move to a more recent 2.4, say 2.4.34.x or 2.4.35? Those are at least semi-recent, and have the newer bugfixes in them.

[Crito]

It's merged into the tree, that makes it part of the kernel. So you're completely wrong.

There is absolutely no need for different SMP and non-SMP kernels as there was with 2.4, which is the point I originally made, and it's still true.

[bwkaz]

You will note that nowhere did I say that SMP alternatives wasn't in the tree.

However, you said:

all current 2.6 kernels are SMP enabled

, but that's wrong. Just because distros can provide a single SMP-enabled kernel that acts very similar to a non-SMP kernel on a UP box due to this code, doesn't mean they have to. It also doesn't mean that "all kernels are SMP enabled". You can still turn off the SMP stuff. That's why CONFIG_SMP still exists. (An SMP kernel on a UP box also doesn't act exactly the same as a UP kernel: there are still extra NOPs.)

There may not be a need for a non-SMP kernel (but it depends on your system: an embedded UP setup will likely turn off SMP, as there are fewer NOPs sitting there taking up cache space), but it's still possible to create one.

You may want to read this LWN article describing how the SMP alternatives works, and why it exists. It's not meant to be used by everyone.