Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Is there not a way to pin processes to cores in linux already, and/or why it cannot be used to achieve a similar thing (pin user1 to cores 0,1 and user2 to cores 2,3)?


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.


Well can't software do that automatically? I would love a piece of software that could reserve a couple of cores for games, another couple of cores for firefox, etc. dynamically based upon some settings.


On a computer that you control completely, in Linux you can use taskset to launch programs on whichever cores you want and to migrate already running programs to whichever cores you like and there is no obstacle that prevents you to use this in some scripts to automatically implement any policies you desire.

I frequently use taskset, because otherwise Linux migrates continuously the process between cores, which can degrade the performance of the programs that do some computations with a long duration, unlike the programs that are mostly waiting for events to happen.

This new feature has a different purpose, it is intended for multiuser servers, to enable the secure partitioning of the runnable threads into groups that can be scheduled on different cores, so that they will not be able to interfere with each other, even when they would have intended that.


Security problems probably. I could only imagine the new spectre vulns if you got to pick your own core.


Sure, you could use cgroups for that.


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?


In Linux, the CPU affinity (i.e. the list of cores on which a thread may be run) is inherited by any child process or thread, from its parent.

Nevertheless, the CPU affinity of any process or thread can be changed at any time with sched_setaffinity() so the httpd process itself could run its children on different cores, if it wanted so, but it is unlikely that any httpd program does this.

The new feature that is discussed in this thread will limit the cores on which the threads of a user can be scheduled to those having the same cookie, so a process will no longer be able to reschedule its children to run on the same core as the threads of another user.


Yes? If CPU X is the only trusted CPU, or you are only trusted to run your software on that CPU, then everything should run on that core. If you rent 12 of 128 cores, then it may run on any of those 12 cores.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: