We need for the JVM to reserve a set number of CPUs. Following my research we can use taskset along with the kernel parameter isolcpus= so that no other process uses this CPU. A few questions arise: - does the process need to be started with taskset? - does the reservation means that the process can only run on that CPU and if there are resources problems it can expand to the other CPUs?

I have a laptop with an Intel Core i7-12700H CPU, running Ubuntu 24.04 LTS. This CPU has 6 “performance“ cores, each one running 2 threads, and 8 “efficient” cores. Most of the time, the “efficient” cores can provide much more power than I need, so I’d rather keep the “performance” cores idle, to save power, and only use the “efficient” ones. Occasionally, I have to run and benchmark some intensive (multi-threaded) computation code. Then I wan to use the “performance” cores, without being disturbed by other processes. I may want either to run a single thread per core, to get the maximum per-thread performance, or to use both threads of each core. At first, I considered using cgroup’s cpusets, with the cset tool. I wrote the following script to create the sets: cset set -c 12-19 --cpu_exclusive -s efficient cset set -c 0-11 --cpu_exclusive -s performance cset set -c 0,2,4,6,8,10 -s performance/no-ht cset proc -m -f root -t efficient It works as expected, but I find it troublesome since I need root to escape the efficient cgroup, with ugly commands like sudo cset proc --exec performance/no-ht -- sudo -u $(whoami) ~/bin/my_code Moreover, because it switches to root, I can’t wrap that whole command in time or a profiler. I can still run time or the profiler within the performance cgroup, but then they share the same cores as the code under test… Hence I considered taskset , with the following command: /usr/bin/time taskset -c 0-11:2 ~/bin/my_code It works as expected, does not need root, but other processes may use the “performance“ cores. One solution is to use both systems, with an awful command like: sudo cset proc --exec root -- sudo -u $(whoami) taskset -c 12-19 /usr/bin/time taskset -c 0-11:2 ~/bin/my_code It works fine but looks over-complicated and still needs root… Then I read about the isolcpus kernel parameter and, despite being deprecated, it looked great to me. So I added isolcpus=0-11 to the GRUB_CMDLINE_LINUX_DEFAULT parameter in /etc/default/grub, ran sudo update-grub and rebooted. At first sight it looked fine, only a few kernel threads were running on CPUs 0 to 11, all userspace processes were running on CPUs 12 to 19. So I tried: /usr/bin/time taskset -c 0-11:2 ~/bin/my_code As expected, OpenMP correctly discovered it could use 6 cores and launched 6 threads, but I figured out all of them were running on CPU 0… I checked the Cpus_allowed_list line in /proc//status and it was correct (0,2,4,6,8,10). Running taskset to allow each thread on a single core works, but it’s not very convenient and does not allow to share load if there are more threads than cores… Any idea why the threads seem to be stuck on the first allowed CPU when using the isolcpus kernel option? Is there a better way to keep everything running on CPUs 12 to 19 by default, like if everything was run through taskset -c 12-19, without using cgroup jails than need root to escape?

When I run taskset -p of a process I am getting something like this back:

# taskset -p 1078
pid 1078's current affinity mask: 3f

And it keeps changing what it reports, sometimes it's 5f, other times df and so on. For the same process I can see that its allowed on all cores:

# cat /proc/1078/status | grep Cpus
Cpus_allowed:   ff
Cpus_allowed_list:      0-7

And its cpuset in cgroups also allows 0-7:

# cat /dev/cpuset/cpus 
0-7

If I try to set it to ff using taskset I still do not get ff back:

# taskset -p ff 1078
pid 1078's current affinity mask: 5f
pid 1078's new affinity mask: 5f

What mechanism is overriding the cpuset and taskset affinity? Any way I can force it to actually run on all cores? This is on Android 13 and kernel 5.15.

My bash script is as follows:

#!/bin/bash
sudo taskset 1 ./program &

When running it does nothing. I am able to run the software normally with ./program. I am attempting to do the behavior of "The default behavior is to run a new command with a given affinity mask"

First, let me give a background of what I am trying to achieve. I know how to isolate a particular CPU using boot param (isolcpu and nohz_full; the housekeeping subsystem setup). But as per my requirement, I need to isolate the CPU after the system has booted up. So, as per many articles, I tried to isolate a particular CPU using cpuset subsystem as follows: I am using a hardware having 16 cpus. (0-15). So, I decided to isolate CPU 0.

$ cd /cpusets
$ mkdir housekeeping
$ mkdir isolate
$ echo 1-15 > housekeeping/cpus
$ echo 0 > mems
$ echo 0 > isolated/cpus
$ echo 0 > isolated/mens
$ echo 0 > cpuset.sched_load_balance
$ echo 0 > isolated/sched_load_balance
$ while read P ; do echo $P > housekeeping/tasks ; done < tasks

This isolates the processor 0 from all the other processors. But when I tried to assign a process to processor 0 using taskset as follows:

-c
/******loop.c**********/
int main(){
    int i;
    for(i=0;;i++);
    return 0;
}

$ gcc -o loop.c loop
$ taskset -c 0 ./loop
taskset: failed to set pid 2755250's affinity: Invalid argument

Apart from echoing pid 2755250 to isolated/tasks, is it possible to set the affinity of a new process to the isolated CPU 0? Where am I making a mistake?

I've got an AMD 7950X3D CPU which has 32 total logical cores, 16 of which (0-15) have access to extra cache. To optimize my system for gaming while multitasking I want to run Steam and all the processes it spawns on cores 0-15 and at the same time restrict the rest of the system to cores 16-31 so that nothing interferes with the games. And I want to be able to set this restriction at runtime, so that the system has all the resources if I'm not running games. To break it down, this would be the workflow: 1. Pin all running and newly spawned processes (except steam) to cores 16-31. 2. Run steam pinned to 0-15. 3. Once I'm done with gaming, allow all running and newly spawned processes to run on 0-31 again. Step 2 is clear, I just run taskset -c 0-15 steam, and this works. But it's not clear to me how to do step 1 and 3. Here is what I tried: sudo taskset -apc 16-31 1. By setting the affinity for the PID 1 with the -a flag I was hoping that it would apply this to all processes spawned by it (which is everything), but it does not do that, it only seems to apply the pinning to all threads of a process, not its already running child processes. In the system monitor I still see cores 0-15 occasionally jumping up to 2% load. And if I run stress -c 32 to test it, it also loads all 32 cores to 100% rather than just 16-31. All the suggestions I found in other similar threads either do not apply at runtime but at startup (changing systemd config files) or are not dealing with all already running processes, so I don't think this is a duplicate. Any suggestions?

when I run taskset -p 242306 I got following output 3ffffffffffc000000000000000000000000000000000000000000038000000 sorry for the long string, there are 256 cores on the box. used taskset -c -p 242306 the output is > pid 242306's current affinity list: 27-29,206-249 but when I run ps -u -o pid,cpuid | grep 242306 I got 242306 131 so the process is actually running on cpu 131 which is disabled in mask above the cpu affinity is set by using cgroup, and the process is ssh-agent. the operating system is Oracle Linux Server release 7.9. one thing worth mentioning is that the process is not really running, it's not consuming any cpu. so maybe the system will randomly assign a cpu core to a process when it's not really using any cpu?

I have a processor-intensive Java program and I want it to use all 8 available cores on the machine. I've run taskset and it reports the mask to be: pid 5897's current affinity mask: ff But in top (when running 12 (heavy) threads): 5897 ubuntu 20 0 9099664 1.7g 18608 S 400.7 11.1 25:52.83 java What's going on here?

I'm running Centos7 on an hyper-threaded Ivy Bridge machine with 40 cores and 80 threads. The following for loop shows me the processor affinity for all processes with pids 10 and then rerun the for loop. The result is as follows: pid 1's current affinity list: 0-9 pid 2's current affinity list: 0-9 pid 4's current affinity list: 0 pid 6's current affinity list: 0 pid 7's current affinity list: 0 pid 8's current affinity list: 0-9 pid 9's current affinity list: 0-9 pid 10's current affinity list: 0-9 pid 11's current affinity list: 0 pid 12's current affinity list: 1 pid 13's current affinity list: 1 pid 14's current affinity list: 1 pid 16's current affinity list: 1 pid 18's current affinity list: 2 pid 19's current affinity list: 2 pid 20's current affinity list: 2 pid 22's current affinity list: 2 pid 24's current affinity list: 3 pid 25's current affinity list: 3 pid 26's current affinity list: 3 pid 28's current affinity list: 3 pid 30's current affinity list: 4 pid 31's current affinity list: 4 pid 32's current affinity list: 4 pid 34's current affinity list: 4 pid 36's current affinity list: 5 pid 37's current affinity list: 5 pid 38's current affinity list: 5 pid 40's current affinity list: 5 pid 41's current affinity list: 6 pid 42's current affinity list: 6 pid 43's current affinity list: 6 pid 45's current affinity list: 6 pid 46's current affinity list: 7 pid 47's current affinity list: 7 pid 48's current affinity list: 7 pid 50's current affinity list: 7 pid 51's current affinity list: 8 pid 52's current affinity list: 8 pid 53's current affinity list: 8 pid 54's current affinity list: 8 pid 55's current affinity list: 8 pid 56's current affinity list: 9 pid 57's current affinity list: 9 pid 58's current affinity list: 9 pid 60's current affinity list: 9 pid 61's current affinity list: pid 62's current affinity list: pid 63's current affinity list: pid 65's current affinity list: pid 66's current affinity list: pid 67's current affinity list: pid 68's current affinity list: pid 70's current affinity list: pid 71's current affinity list: pid 72's current affinity list: pid 73's current affinity list: pid 74's current affinity list: pid 75's current affinity list: pid 76's current affinity list: pid 77's current affinity list: pid 78's current affinity list: pid 80's current affinity list: The affinity for process with pid = 1, now shows up as 0-9 instead of 0-79. This is what I expected. However processes with pids between 66 and 80 are shown to have no affinity list. Does that mean their affinity lists are 0-9, or something else? The system seems to work just fine so these processes without affinity must be doing their jobs. There are of course many other processes with original affinities set to processors which have been disabled. Rather than showing almost 1000 lines of output, I've just shown the results for the first 80 processes.

I found the pid of my process. I ran taskset on the pid:

$ taskset -p 2059
pid 2059's current affinity mask: e

What does this affinity mask value "e" mean? I do not see anything about the possible output values in the [taskset docs](https://linux.die.net/man/1/taskset) . The man pages are the same as the docs.

I'm trying to write at the beginning of my script some code that will ensure every command inside the script is run on just a few specific cores. even if many commands are run in multiple parallels like : [command] & [command] & [command] & [command] & [command] , I want them to only run on the few selected cores. Currently the script looks for its own PID when it starts, and then feeds that into taskset, where I tell it that its PID is only allowed to use cores 1 to 3. An example taskset command looks like: taskset -c 1-3 -p 45678 But as soon as some parallel commands start, they each get there own PID and are know longer restricted to the allocated cores. How do I make sure everything in the script stays in the desired cores?

I'm running online servers for a physics-based game with a backend in Node.js. Currently, the server can handle 10 games/worlds at a time before the next tick needs to be executed. With this in mind, I have tight scheduling using nanotimer so that the world steps don't step on each other's toes, but the ordering also means that I can only run on one processor, so my AWS instances are only sitting at about 55% CPU utilization. I decided using taskset would be a good way of going about using both processors on my instance, but sometimes the worlds are blocked from processing for several seconds at times by what I imagine is another exterior process running. How can I prevent this from happening? If I'm using two of the processors (without taskset), the one set of worlds runs just fine, but I'm only using 55% of my processor, which is really expensive.

Being on Linux I have "CPUAffinity= 0 1 3" set in system.conf. I also use "taskset -cp 2 $pid" to assign a CPU to a single process. But what does the CPU consumption for the process in top now mean? Let's say it is 20%. Is it 20% for the single CPU or 20% for all CPUs?

I want to limit the processing capability to only a single core in my machine, so I found out taskset can help to set a single core, say core 0, as the following (Courtesy to this answer ): taskset -c 0 -p 45678 The problem is that how can I determine the process_id pid here when my program is not running yet? Do we just set an arbitrary process id to be picked up by Linux, in this case 45678? If it is so, is it possible to do that in a shell script as the following: #!/bin/sh # Set the processing unit taskset -c 0 -p 45678 # run python script python main.py

I have a process, shell. It's affinity mask is 1 (I have 3 CPUs) On redundant machine (almost mirror - it is 7 - ALL CPUs) Who is deciding which mask to set or where it is configured? [root@h1-nms ~]# ps $$ PID TTY STAT TIME COMMAND 7605 pts/2 Ss 0:00 -bash [root@h1-nms ~]# taskset -p $$ pid 7605's current affinity mask: 1

I work with a Red Hat Enterprise Linux Server release 6.9 (Santiago) (I don't manage it). In the GRUB config file we have, let's say, isolcpus=2-32 (out of 36 cores). I also have a **cgroup** with cpuset=2-32 assigned via cgset.conf to all important processes on that system. My question is: how do these 2 settings interact? Normally, when I have isolcpus, starting a process with taskset -c 2-32 means all threads end up on core 2 as isolcpus "removes cores from scheduler" as I was told so there is no load balancing. However, the observed effect of cpuset cgroup is different from taskset - the various processes and threads end up on different cores. Could someone explain how isolcpus with taskset command produces one result, while isolcpus with cgroups/cpusets produce a different one?

I have the following code in a bash script: echo "bash pid => $$"; echo "processor affinity before => $(taskset -p $$)" taskset -cp ${AN_INTEGER} $$ echo "processor affinity after => $(taskset -p $$)" I get this output: processor affinity before => pid 5047's current affinity mask: ff pid 5047's current affinity list: 0-7 pid 5047's new affinity list: 1 processor affinity after => pid 5047's current affinity mask: 2 does anyone know what this means? The reason I started messing with processor affinity is because I would launch multiple bash child processes, and all the bash child process affinities had the value "ff" so it seemed like they were all targeting the same CPU.