•

The Linux kernel has been accidentally hardcoded to a maximum of 8 cores for nearly 20 years

The Linux kernel has been accidentally hardcoded to a maximum of 8 cores for the past 15 years and nobody noticed

https://thehftguy.com/2023/11/14/the-linux-kernel-has-been-accidentally-hardcoded-to-a-maximum-of-8-cores-for-nearly-20-years/

A bit of history I’ve been diving into the Linux kernel scheduler recently. To give a short brief introduction to scheduling, imagine a single CPU single core system. The operating system all…

The Linux kernel has been accidentally hardcoded to a maximum of 8 cores for the past 15 years and nobody noticed

I'm not smart enough to verify the accuracy of this claim, nor exactly what the implications are, but it seems like it might improve performance if fixed.

6 comments

Frederic

•

Title bullshit, we have multicore machine for years, I can guarantee you this had about no impact else people running Xeon or Threadripper would have saw it at first try 15 years ago.

This looks like to have an impact on the scheduler but not on how many cores are used.

drwho

•

I agree. Some of the Linux servers I used to run at work in the early 00's were 12 to 16 core monsters (for the time) and the kernel didn't even blink.

AernaLingus

•

There's a variable that contains the number of cores (called cpus) which is hardcoded to max out at 8, but it doesn't mean that cores aren't utilized beyond 8 cores--it just means that the scheduling scaling factor will not change in either the linear or logarithmic case once you go above that number:

::: spoiler code snippet

/*
 * Increase the granularity value when there are more CPUs,
 * because with more CPUs the 'effective latency' as visible
 * to users decreases. But the relationship is not linear,
 * so pick a second-best guess by going with the log2 of the
 * number of CPUs.
 *
 * This idea comes from the SD scheduler of Con Kolivas:
 */
static unsigned int get_update_sysctl_factor(void)
{
	unsigned int cpus = min_t(unsigned int, num_online_cpus(), 8);
	unsigned int factor;

	switch (sysctl_sched_tunable_scaling) {
	case SCHED_TUNABLESCALING_NONE:
		factor = 1;
		break;
	case SCHED_TUNABLESCALING_LINEAR:
		factor = cpus;
		break;
	case SCHED_TUNABLESCALING_LOG:
	default:
		factor = 1 + ilog2(cpus);
		break;
	}

	return factor;
}

:::

The core claim is this:

It’s problematic that the kernel was hardcoded to a maximum of 8 cores (scaling factor of 4). It can’t be good to reschedule hundreds of tasks every few milliseconds, maybe on a different core, maybe on a different die. It can’t be good for performance and cache locality.

On this point, I have no idea (hope someone more knowledgeable will weigh in). But I'd say the headline is misleading at best.

madasi

•

I took the title from the link, which doesn't exactly match the title on the page. That's why one says 20 years and the other says 15 years.

Pantherina

•

Heard of that, because you know, a core Duo was a thing. They didnt think anything bigger was possible, some time in the past. But afaik thats pretty old news

merthyr1831

•

Would've been nice of them to compile the kernel with a fix applied to see how much of an impact it has (though even in the post they seem to suggest that it's not that impactful unless you run massive clusters)

/* * Increase the granularity value when there are more CPUs, * because with more CPUs the 'effective latency' as visible * to users decreases. But the relationship is not linear, * so pick a second-best guess by going with the log2 of the * number of CPUs. * * This idea comes from the SD scheduler of Con Kolivas: */ static unsigned int get_update_sysctl_factor(void) { unsigned int cpus = min_t(unsigned int, num_online_cpus(), 8); unsigned int factor; switch (sysctl_sched_tunable_scaling) { case SCHED_TUNABLESCALING_NONE: factor = 1; break; case SCHED_TUNABLESCALING_LINEAR: factor = cpus; break; case SCHED_TUNABLESCALING_LOG: default: factor = 1 + ilog2(cpus); break; } return factor; }