Core Scheduling Looks Like It Will Be Ready For Linux 5.14 To Avoid Disabling SMT/HT

[phoronix]

Phoronix: Core Scheduling Looks Like It Will Be Ready For Linux 5.14 To Avoid Disabling SMT/HT

It looks like the years-long effort around CPU core scheduling that's been worked on by multiple vendors in light of CPU security vulnerabilities threatening SMT/HT security will see mainline later this summer with Linux 5.14...

https://www.phoronix.com/scan.php?page=news_item&px=Core-Scheduling-Linux-5.14

[waxhead]

I have not put too much effort into teaching me what this is all about , but as far as I can understand it is all about "partitioning" your CPU's and locking certain tasks to certain CPU's. How is this done? Can you assign Cgroups to a particular set of CPU's and can you migrate the tasks/cgroup across one set of CPU's to another?

[droste]

I think you got it the wrong way around.
The idea is not to lock a task to a CPU core, but to make sure while a trusted thread is running on a specific CPU core, an untrusted thread is not run in parallel (SMT) on the same core.
Threads from the same trusted application can still run in parallel on the same core as well as all application that don't require the security (games for example) can run in parallel.
So you only use a little performance on a specific core while the thread of a trusted application is running there. And maybe not even that if the same application has multiple threads that can run in parallel.

[waxhead]

I think you got it the wrong way around.
The idea is not to lock a task to a CPU core, but to make sure while a trusted thread is running on a specific CPU core, an untrusted thread is not run in parallel (SMT) on the same core.
Threads from the same trusted application can still run in parallel on the same core as well as all application that don't require the security (games for example) can run in parallel.
So you only use a little performance on a specific core while the thread of a trusted application is running there. And maybe not even that if the same application has multiple threads that can run in parallel.

Thanks, but I don't think I got it the wrong way around. Perhaps I worded it badly. But how is this achieved? Is it by setting CPU affinity for a group of processes temporarily while assigning a special "do not run" affinity for other processes (untrusted) while the trusted ones run. And is this "permanent" in the way that processes are locked to the CPU's / Cores "forever" or it is more flexible e.g. looking also at what processes are executing at the moment? How does the scheduler know which is trusted or not - is this done with cgroups?

[droste]

As far as I understand a process (or a group of processes) can be assigned a "cookie" via the new API. When a process that has a cookie assigned to it is executed on a CPU core only threads from processes with the same cookie are allowed to run simultaneously on that core. The cookie assignment is done via the new kernel API (no cgroups right now). One or more processes can be assigned the same cookie so they can be executed simultaneously on the same core. These are the "trusted" ones.
The processes are not locked to a core or CPU.