Linux World News recently reported that the kernel dev team is moving away from uniprocessor kernel configurations.

The Linux kernel famously scales from the smallest of systems to massive servers with thousands of CPUs. It was not always that way, though; the initial version of the kernel could only manage a single processor. That limitation was lifted, obviously, but single-processor machines have always been treated specially in the scheduler. That longstanding situation may soon come to an end, though, if this patch series from Ingo Molnar makes it upstream.

This doesn’t mean Linux will stop working on single-processor machines.  What it means is that all the special code in the kernel (a long series of #ifdefs) to make uniprocessor code work better will be stripped out.

When you enable CONFIG_SMP, the kernel enables a lot of code to make SMP possible.  If this isn’t done, only one core will be recognized.  This patch will essentially make CONFIG_SMP always selected.

In modern environments, single-core systems are increasingly rare.  Even a Raspberry Pi Zero 2 is a quad core.  Yes, you can certainly find single-core systems, particularly in the embedded space, but this proposed patch is just reflecting reality.

When Linux was first released (early 90s), very few people had dual core systems on their desk.  Nowadays, trying to find a desktop system that has less than 4 cores is very hard.  And the server space has been multicore since forever.

So what’s the impact if you take a kernel a year from now that has CONFIG_SMP turned on and run it on a unicore machine?  Very little.  What’s being proposed will impact the scheduler, and the scheduler is slightly less efficient when it has to “think in SMP terms” on a single-core system.  But we’re talking ~5% efficiency gain if you’re hitting the scheduler really hard, and the odds are, you’re not.

In fact, you’re probably already doing this.  All the distros ship with CONFIG_SMP turned on, so unless you’re specially compiling a unicore kernel, you already know how this will perform.

raindog308

Raindog308 is a longtime LowEndTalk community administrator, technical writer, and self-described techno polymath. With deep roots in the *nix world, he has a passion for systems both modern and vintage, ranging from Unix, Perl, Python, and Golang to shell scripting and mainframe-era operating systems like MVS. He’s equally comfortable with relational database systems, having spent years working with Oracle, PostgreSQL, and MySQL.

As an avid user of LowEndBox providers, Raindog runs an empire of LEBs, from tiny boxes for VPNs, to mid-sized instances for application hosting, and heavyweight servers for data storage and complex databases. He brings both technical rigor and real-world experience to every piece he writes.

Beyond the command line, Raindog is a lover of German Shepherds, high-quality knives, target shooting, theology, tabletop RPGs, and hiking in deep, quiet forests.

His goal with every article is to help users, from beginners to seasoned sysadmins, get more value, performance, and enjoyment out of their infrastructure.

You can find him daily in the forums at LowEndTalk under the handle @raindog308.