For anyone still happening to have only one CPU core in their system and running a uni-processor "UP" kernel build without any simultaneous multi-processing (SMP) support enabled, a big patch series posted today for the Linux kernel may affect you.

Even embedded systems and years-old Intel Celeron processors selling for ~$20 retail these days offer at least two physical CPU cores. The days of having only a single CPU core and be running a uniprocessor "UP" kernel configuration are extremely rare in 2025. A patch series posted today to the Linux kernel mailing list is looking to acknowledge the reality of the very rare UP kernel usage in recent years and in turn rely on the SMP kernel scheduler for UP use-cases.

It's been two decades since reviewing any single core CPUs on Phoronix.

Longtime Linux developer Ingo Molnar posted a set of 43 patches today for standardizing the Linux scheduler on the SMP variant to reduce the complexity and coding mess for dealing with non-SMP cases within the scheduler code. Ingo explained in the patch series:

"This series implements an idea Peter Zijlstra has mentioned before: standardize the Linux scheduler on the SMP variant to drastically reduce the number of CONFIG_SMP blocks of code and related complexity in the scheduler.

Today the Linux scheduler has an obscene amount of CONFIG_SMP preprocessor blocks of code, where UP code diverges from SMP code:

$ git grep CONFIG_SMP kernel/sched/ | grep -v endif | wc -l

175

Which is substantial complexity that regularly results in build failures and the occasional boot failure when people develop on CONFIG_SMP and (naturally) don't immediately test on !CONFIG_SMP.

These build and boot failures are in fact under-reported in the upstream kernel Git history, because they tend to be triggered on developer systems: but they are still there and they are still an ongoing development and maintenance cost. It's rare to see a larger scheduler patch series that doesn't have some sort of build complication on !SMP.

Another problem is that these literally 175 separate blocks of preprocessor code make the scheduler code harder to review and harder to understand.

All the while most modern hardware platforms - even embedded ones - tend to have two or more CPUs and use SMP kernels these days.

So there's an ongoing and largely hidden burden of maintenance and cost of complexity on scheduler developers."

Thus the 43 patches adapt the SMP scheduler to be used on Linux UP kernel builds too. There is significant immediate code savings right away and reduced complexity for Linux kernel developers moving forward in not having to worry about any UP code paths there.

Ingo does acknowledge though that this will lead to some bloat for anyone still relying on a UP kernel:

"Note that the approach I chose is pretty blunt and straightforward, to make sure this conversion is as bug-free as possible. I'd rather bloat the UP scheduler a bit than to break it.

...

The second part of the series converts the UP scheduler to the SMP scheduler. The biggest patch:

sched/smp: Make SMP unconditional

Ended up being rather large and monolithic, and there's no easy way I can see to increase granularity there without breaking the scheduler in the interim step: because there's no clear separation of various aspects of the UP/SMP scheduler, other than a humunguous amount of #ifdef CONFIG_SMP blocks we grew over ~25 years...

Once that first large step was done, it was easier to do the rest more gradually.

Note that much of the extra SMP code is unused code that will never be triggered on a UP kernel - such as load-balancing, but there's some extra context switching overhead on UP kernels:

$ perf stat --null --sync --repeat 5 perf bench sched pipe

# Before: 2.55022 +- 0.00308 seconds time elapsed ( +- 0.12% )

# After: 2.68700 +- 0.01600 seconds time elapsed ( +- 0.59% )

Kernel size impact (on x86-defconfig+!CONFIG_SMP):

text data bss dec hex filename

28816070 7720174 1837328 38373572 24988c4 vmlinux.defconfig.nosmp.before

28904324 7735982 1817876 38458182 24ad346 vmlinux.defconfig.nosmp.after

+0.3% text, +0.2% data.

But at this point I think the burden of proof and the burden of work needs to be reversed: and anyone who cares about UP performance or size should present sensible patches to improve performance/size."

So there will be some additional overhead for any UP Linux users remaining, but chances are if you still are relying on a single CPU core system in 2025+, you likely aren't running the latest and greatest kernel either...

For now this work-in-progress code to make the SMP scheduler used on uniprocessor kernels can be found on the [1]Linux kernel mailing list .



[1] https://lore.kernel.org/lkml/20250528080924.2273858-1-mingo@kernel.org/