Core scheduling lands in Linux 5.14

Technical writing with a sense of humor is great. Highly recommended: the user manual of the SkyRC MC3000 Li-Ion charger.

A majority of long form writing is extremely low information density and, even worse, just designed to retain attention as long as possible. I now dislike majority of news articles which starts with pseudo-literary description of anecdot and a main detail is revealed 3/4 of the way in sentence or two. It’s purely filler and like sugar it has a purpose. I want all long form writing to have sub title to tell the core of story in one line, followed by abstract, or let Twitter guy summarize it for me.

Maybe I'm just being too humorless, but I found the quoted passage a bit too dismissive of all the good things that are being done in cloud environments. Some of us are developing products that actually make people's lives better, and we're selling those products as SaaS, but we're not yet big enough to operate dedicated hardware with the same level of reliability and security that, say, AWS can achieve, so we run in a shared cloud environment. Anyway, the constant cynicism in online communities like this one, and reflected in that part of the OP, gets to me.

> longform plain text

Lol it's just a thousand words!

Core pinning exists but it requires the administator to manually assign processes to specific cores. Core scheduling lets you group trusted processes together and then the OS can figure out which cores can run which processes dynamically. Also, core scheduling does not permit userspace attackers to "game the system" and target a specific core they want to attack.

A process running httpd httpd is pinned to CPU X. And it forks right away 10 worker sub-processes. Are all sub-processes supposed to run on CPU X?

Yea, I'm curious what they even mean by 'performance' in this context.

It would obviously impact whole-system performance, since this setting would intentionally limit what can run on each core leading to some idle cycles. That's expected though, and is merely a consequence of using this feature for security.

I'm curious if it measurably slows down the scheduler and impacts performance from there.

It's a leaky abstraction over the underlying system call mechanism. Because the user stack lives in user space and accessing it from the kernel requires the same dance as any other access to user memory, system call arguments are instead passed in registers where they are immediately available to the kernel with no possibility of faults or TOCTTOU holes.

Here 'unsigned long' is just a convenient stand-in for "generic register-sized argument".

A "void * pointing to struct" requires a copy from user space. If a particular prctl() does need a struct, it can certainly stuff a pointer into one of those 'unsigned long' parameters (in the kernel environment, a pointer can be converted to and from an unsigned long without concern).

prctl is responsible for setting certain privileged CPU registers on certain platforms. I can imagine some benefit of having the values already loaded into registers for such a brief call instead of having to go out to user-controlled memory (which needs to be accessed carefully within the kernel).

It’s also worth noting that most older Linux system calls do not follow that pattern in general, so I don’t know that I would consider void* idiomatic for system calls until recently.

Because it is much cleaner to name the arguments rather than to have a void* to what may or may not be the same struct floating somewhere in space.

Because this is the most general signature possible (in general syscalls can have up to 6 arguments because the kernel supports x86-32 which has only 8 general purpose registers of which one stores the syscall number, one the stack pointer which cannot be reused due to signals in case of no sigaltstack, and the remaining 6 are available).

Depending on option, the args can be pointers to structure.

What you're describing sounds like a superscalar processor which utilizes instruction level parallelization: https://en.wikipedia.org/wiki/Superscalar_processor

As someone else said, this is superscalar, though these days companies refer to the number of concurrent out-of-order pipelines as Execution Units (EUs).

SMT is a second set of registers that uses the same execution hardware. If a thread stalls waiting for a main memory read then the other thread can jump in after the pipeline is cleared out (or maybe before if you're clever and careful, but idk if this is done in practice). You can also impose some governance over time sharing so threads with low data memory footprints don't lock out other threads.

No, it's not. SMT is specifically when you're running two threads simultaneously on a superscalar processor that can execute multiple instructions in a single cycle. During SMT one thread might be using execution reasources the other thread doesn't need further increasing performance beyond just having something to do during a cache miss.

What the article describes is temporal multithreading where only one thread executes at a time.

https://en.wikipedia.org/wiki/Multithreading_(computer_archi...