LWN: Comments on "An end to uniprocessor configurations"

Optimizing for one CPU

iabervon — Sat, 14 Jun 2025 20:17:24 +0000

You could just say that a 0-bit integer has enough padding to use up one whole address, so its size is 1. 1-bit integers have enough padding to have an integer size, and you could just say that any type that doesn't need any space for data at all still has to get to size(type) >= 1 by having padding. That would still allow for entirely optimizing out void local variables whose addresses aren't taken, and specifying ABIs such that void arguments are passed in registers without using any registers. And, actually, the clang/gcc pointer arithmetic for void* would make sense if each void item was enough padding to get a new address without any space used to store data.

Optimizing for one CPU

alx.manpages — Sat, 14 Jun 2025 18:15:54 +0000

_Generic already works with void in GCC 15:

alx@debian:~/tmp$ cat g.c
int
main(void)
{
return _Generic(void, void: 1);
}
alx@debian:~/tmp$ /opt/local/gnu/gcc/countof/bin/gcc -Wall -Wextra g.c
alx@debian:~/tmp$ ./a.out; echo $?
1

Optimizing for one CPU

quotemstr — Sat, 14 Jun 2025 18:03:51 +0000

Yeah. You're right. The void* arithmetic thing settles it. It's a shame; the void as value C++ paper from a few years ago would have filed off a lot of metaprogramming edges.

Maybe it'd at least make sense to let _Generic work with void as an exception to the general rule against incomplete types?

Optimizing for one CPU

khim — Sat, 14 Jun 2025 17:25:00 +0000

> Simple and surprisingly powerful change.

Yes. Powerful enough to destroy countless programs.

You may take a look on Rust: it does gave zero sized types (and Rust's void is also zero-sized tuple). To make that work they had to include tons of checks everywhere.

Simply because now you, suddenly can take double your vector size as many times as you want without ever running out of memory. And do bazillion other similar things.

Plus clang/gcc have already adopted pointer arithmetic for void*, having actual zero-sized type would cause compatibility issues there, too.

Optimizing for one CPU

khim — Sat, 14 Jun 2025 17:20:01 +0000

C doesn't even have zero-sized type and that one is much more useful.

Unfortunately the assumption that any type have size of least one is used in bazillion places, thus it's hard to change that.

Optimizing for one CPU

quotemstr — Sat, 14 Jun 2025 15:02:10 +0000

If you're going to do that, please also consider making void a vacuous value type instead of a special keyword. Simple and surprisingly powerful change. You'd be able to write, say, void x = foo(); bar(x).

Kernel size

andy_shev — Fri, 13 Jun 2025 16:45:02 +0000

And 20 releases ca. +1 Mb, from v3.0 to v6.19 will be +4 Mb :-) At least kernel becomes so bif somewhere in v6.x cycle that it makes me to look deeper in the one issue on one of the x86 boards... For curious: https://lore.kernel.org/all/20230830102434.xnlh66omhs6nin...

Wi-Fi access points and home routers: Single-core and size constraints

taladar — Fri, 13 Jun 2025 07:51:37 +0000

But if you delay that it also effectively means maintaining the uniprocessor ifdef mess for many more years and most likely having backport headaches around the removal of that in newer releases.

LTS users always think of the pain in losing features but not the pain of keeping them for everyone else.

Wi-Fi access points and home routers: Single-core and size constraints

marcH — Thu, 12 Jun 2025 18:25:56 +0000

Thanks, it's about 100K increase with x86-defconfig. Probably smaller for embedded systems.

Kernel size

geert — Thu, 12 Jun 2025 18:18:18 +0000

Every new kernel release increases binary kernel size by ca. 25 KiB.

An m68k atari_defconfig kernel gained 32 KiB between v6.15 and v6.16-rc1, of which ca. 10 KiB can be attributed to the console Unicode fixes.

A reasonable move

wtarreau — Thu, 12 Jun 2025 16:25:48 +0000

Indeed I also agree that it's acceptable to lose a bit of performance on older systems for the sake of simplicity and possibly improving support for newer systems. The size increase might be a bit more controversial for some deeply embedded environments, but that's probably not much more than what comes with each new kernel version anyway. The old days of a 500kB compressed kernel image are long gone I think.

Wi-Fi access points and home routers: Single-core and size constraints

mr_bean — Wed, 11 Jun 2025 20:23:44 +0000

No, OpenWRT 24.10.1 (the current release) is at 6.6.74 and snapshot is at 6.12

Wi-Fi access points and home routers: Single-core and size constraints

hmh — Wed, 11 Jun 2025 18:47:28 +0000

It would be quite enough to delay the merge of UP removal to after the next long-term-support kernel is cut, I think.

Current LTS kernels are going to EOL on 2027 according to kernel.org, which is a bit too close for comfort, IMO.

Wi-Fi access points and home routers: Single-core and size constraints

parametricpoly — Wed, 11 Jun 2025 16:16:24 +0000

I think OpenWRT is currently still at kernel 5.15. The latest release is 6.15. It will take a while before they'll adopt this kernel with mandatory SMP support. There are still 3 more recent LTS kernels available to choose from before they must adopt this.

Also that crap < $50 device is almost 7 years old already.

Wi-Fi access points and home routers: Single-core and size constraints

mb — Wed, 11 Jun 2025 15:52:43 +0000

That's true. That's why you can find the absolute numbers in the patch description.

Optimizing for one CPU

alx.manpages — Wed, 11 Jun 2025 15:45:49 +0000

Yes, for consistency with 2's complement used elsewhere, the non-zero value in _BitInt(1) must be -1. Consensus seems to be forming that if we standardize it, it should be -1 and not 1.

Wi-Fi access points and home routers: Single-core and size constraints

nix — Wed, 11 Jun 2025 15:39:52 +0000

The cost is 5% *during a benchmark that stresses the scheduler*. Almost no uniprocessor use cases do that, because if they stress the scheduler routinely, they are probably overloaded, correspondingly slow at doing any of the jobs they're doing, and are likely to be replaced with something multicore as soon as anyone notices.

The cost here is borne by the maintainers, no matter what. Keeping the uniprocessor scheduler as an option means either keeping the nightmare ifdef maze (no thanks), or *duplicating* the scheduler via unifdef or something, and hoping that changes outside the ifdef maze are maintained in parallel (and usually they have to be maintained or the uniprocessor scheduler will break, hardly anyone will notice, and we're right back where we started). I doubt anyone would be terribly happy with that approach, either...

Optimizing for one CPU

willy — Wed, 11 Jun 2025 14:28:01 +0000

_BitInt(1) would support two values, 0 and -1? I can see the use, but also the confusion. I think there were similar problems with "signed int x:1;"

Wi-Fi access points and home routers: Single-core and size constraints

marcH — Wed, 11 Jun 2025 14:24:35 +0000

> There's a cost to maintaining support for features that almost nobody uses.
> And at some point the people needing this feature should pay the cost or let it go.

Speaking of which, I don't find the "0.3% size increase" a useful metric... Doesn't this scheduler change have a mostly _fixed_ size cost, mostly independent of how many gazillions drivers you enable?

Optimizing for one CPU

alx.manpages — Wed, 11 Jun 2025 10:49:52 +0000

We're talking in the C Committee about adding _BitInt(1) (C23 only supports _BitInt(2) and unsigned _BitInt(1), but not _BitInt(1)). Maybe it would be interesting to discuss adding support for 0 bits as well. I can forward this idea to the committee.

maxcpus=1?

arnd — Wed, 11 Jun 2025 09:47:14 +0000

Not even that, the series specifically removes the special case for CONFIG_SMP=n in the scheduler, not anywhere else.

You can still build a kernel with SMP disabled, and it will still use the trivial implementation of per-cpu data, spinlocks, smp barriers etc, which is where most of the performance and size advantages are for non-SMP builds.

There is currently no way to build an SMP kernel for a lot of the older embedded architectures that lack the required CPU instructions or the irqchip for SMP: ARMv5, most MIPS32r2, PowerPC8xx, m68k, SH3/SH4, ARCompact, microblaze, nios2, and xtensa.

Wi-Fi access points and home routers: Single-core and size constraints

Wol — Wed, 11 Jun 2025 08:23:00 +0000

All the more reason for being able to swap schedulers in and out?

Shouldn't a uni-processor scheduler just be an option? If the users can't be bothered to maintain it, it'll bit-rot. And as a compile-time option or whatever, the cost will be borne by the people who use it, which is as it should be.

Cheers,
Wol

maxcpus=1?

tamiko — Wed, 11 Jun 2025 06:42:11 +0000

This should continue to work. The patch set is about removing the CONFIG_SMP configuration option.

Wi-Fi access points and home routers: Single-core and size constraints

PengZheng — Wed, 11 Jun 2025 02:29:03 +0000

As an embedded system developer, I saw lots of uni-processor systems, and don't expect this situation to change in the foreseeable future.

Optimizing for one CPU

iabervon — Wed, 11 Jun 2025 02:24:12 +0000

I was thinking of NR_CPUS == 1, and I was thinking that the reason this wasn't supported was that cpuids were put in a field that is log(NR_CPUS) bits, which doesn't work in C because you can't have 0-bit fields. But it looks like it's actually fine to have NR_CPUS == 1 and should optimize pretty well, although the compiler probably won't figure out that any two cpuids are the same if NR_CPUS == 1.

Optimizing for one CPU

wahern — Wed, 11 Jun 2025 00:24:38 +0000

What does NR_CPUS == 0 mean?

Optimizing for one CPU

iabervon — Tue, 10 Jun 2025 23:25:53 +0000

I'm a bit surprised, upon thinking about it, that C doesn't have an unsigned 0-bit integer type that you'd use if you set NR_CPUS to 1. It seems to me like a great way of getting code that your compiler can optimize really well: as an lvalue, you can only set it to 0, which doesn't have any effect, and as an rvalue, it's a compile-time constant 0. Then, a ton of code just goes away that would have been necessary if the size wasn't 0.

Non-Wintel architecture?

Kamilion — Tue, 10 Jun 2025 22:36:01 +0000

I'm confused. How would this affect something like the Rockchip RV1103G2 or RV1106? Those are uniprocessor ARM Cortex designs with a clock speed around 1Ghz. Does it just mean it will be running an SMP kernel with the additional memory usage by the structures? Or does it mean it becomes unsupportable post 6.16/6.17 with this patchset? What about all the M68K systems? riscv32imac?

[Research begins in another tab...]

Seems I've answered my own question. Having a look at their kernel config, I can see that SMP is already enabled in their buildroot.

Okay, yeah, I can get behind the mentality here of "finding a uniprocessor doing something non-trivial in the wild, running tip of mainline linux, is incredibly rare". My luckfox pico pretty much only runs gpsd, and only because that was tremendously saner than trying to write my own firmware image with micropython on a pi pico, for a minimal difference in cost.

I see a *lot* of uniprocessor devices with a SDK along for the ride, typically with an android-derived kernel 5.10 -- so that's pretty distant from tip of mainline, and thus easier to find in the wild.

Wi-Fi access points and home routers: Single-core and size constraints

daroc — Tue, 10 Jun 2025 20:29:26 +0000

Also, the kernel will continue to run on uniprocessor machines; scheduling will just be less efficient because it will use the multiprocessor-adapted scheduler.

Wi-Fi access points and home routers: Single-core and size constraints

mb — Tue, 10 Jun 2025 20:19:45 +0000

You can still pick an LTS kernel that doesn't have this change and go one for another couple of years.

There's a cost to maintaining support for features that almost nobody uses.
And at some point the people needing this feature should pay the cost or let it go.
OpenWRT is free to patch a custom small specialized scheduler into their kernel, too. I doubt it's worth it, though.

Wi-Fi access points and home routers: Single-core and size constraints

hailfinger — Tue, 10 Jun 2025 20:08:40 +0000

There are quite a few Wi-Fi access points and home routers with only a single CPU core. OpenWrt supports them and gives them a new life even after the manufacturer doesn't care anymore.

A prominent recent example is the TP-Link Archer C6 v2 router/access point with 802.11ac Wi-Fi. At least in Europe, this device is rather popular among OpenWrt users (affordable, reliable, reasonable range, somewhat recent Wi-Fi). It only has a single core and crucially only has 8 MiB flash space where you have to fit a kernel and all userspace software. For that configuration, a size difference of a few kilobytes may be the difference between shipping a standard OpenWrt or a trimmed down version with reduced functionality.

maxcpus=1?

marcH — Tue, 10 Jun 2025 20:06:32 +0000

This was probably too obvious to even mention but just to be on the safe side... will maxcpus=1 still be available? It's very useful for testing purposes (finding races etc.)