Linux: how to know which processes are pinned to which core?

Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
Is there a way to know which cores currently have a process pinned
to them?
Even processes ran by other users should be listed in the output.
Or, is it possible to try pinning a process to a core but
fail in case the required core already has a process pinned to it?
PS: processes of interest must have bin pinned to the given cores, not just
currently running on the given core
PS: this is not a duplicate, the other question is on how to ensure exclusive use of one CPU by one process. Here we are asking how to detect that a process was pinned to a given core (i.e. cpuset was used, not how to use it).
linux cpu process-management high-performance
add a comment |Â
up vote
2
down vote
favorite
Is there a way to know which cores currently have a process pinned
to them?
Even processes ran by other users should be listed in the output.
Or, is it possible to try pinning a process to a core but
fail in case the required core already has a process pinned to it?
PS: processes of interest must have bin pinned to the given cores, not just
currently running on the given core
PS: this is not a duplicate, the other question is on how to ensure exclusive use of one CPU by one process. Here we are asking how to detect that a process was pinned to a given core (i.e. cpuset was used, not how to use it).
linux cpu process-management high-performance
see thetasksetcommand
â Patrick
Feb 19 at 4:23
A somewhat controversial part of our system is that questions donâÂÂt have to be the same question to be duplicates.â All that is required is that the answer to questionâ¯B is present in questionâ¯AâÂÂs thread.â If you have fully read the answer to How to ensure exclusive CPU availability for a running process? and tried everything that looks relevant to your question, say that.
â Scott
Feb 27 at 1:02
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Is there a way to know which cores currently have a process pinned
to them?
Even processes ran by other users should be listed in the output.
Or, is it possible to try pinning a process to a core but
fail in case the required core already has a process pinned to it?
PS: processes of interest must have bin pinned to the given cores, not just
currently running on the given core
PS: this is not a duplicate, the other question is on how to ensure exclusive use of one CPU by one process. Here we are asking how to detect that a process was pinned to a given core (i.e. cpuset was used, not how to use it).
linux cpu process-management high-performance
Is there a way to know which cores currently have a process pinned
to them?
Even processes ran by other users should be listed in the output.
Or, is it possible to try pinning a process to a core but
fail in case the required core already has a process pinned to it?
PS: processes of interest must have bin pinned to the given cores, not just
currently running on the given core
PS: this is not a duplicate, the other question is on how to ensure exclusive use of one CPU by one process. Here we are asking how to detect that a process was pinned to a given core (i.e. cpuset was used, not how to use it).
linux cpu process-management high-performance
edited Feb 27 at 0:16
asked Feb 19 at 2:59
daruma
393
393
see thetasksetcommand
â Patrick
Feb 19 at 4:23
A somewhat controversial part of our system is that questions donâÂÂt have to be the same question to be duplicates.â All that is required is that the answer to questionâ¯B is present in questionâ¯AâÂÂs thread.â If you have fully read the answer to How to ensure exclusive CPU availability for a running process? and tried everything that looks relevant to your question, say that.
â Scott
Feb 27 at 1:02
add a comment |Â
see thetasksetcommand
â Patrick
Feb 19 at 4:23
A somewhat controversial part of our system is that questions donâÂÂt have to be the same question to be duplicates.â All that is required is that the answer to questionâ¯B is present in questionâ¯AâÂÂs thread.â If you have fully read the answer to How to ensure exclusive CPU availability for a running process? and tried everything that looks relevant to your question, say that.
â Scott
Feb 27 at 1:02
see the
taskset commandâ Patrick
Feb 19 at 4:23
see the
taskset commandâ Patrick
Feb 19 at 4:23
A somewhat controversial part of our system is that questions donâÂÂt have to be the same question to be duplicates.â All that is required is that the answer to questionâ¯B is present in questionâ¯AâÂÂs thread.â If you have fully read the answer to How to ensure exclusive CPU availability for a running process? and tried everything that looks relevant to your question, say that.
â Scott
Feb 27 at 1:02
A somewhat controversial part of our system is that questions donâÂÂt have to be the same question to be duplicates.â All that is required is that the answer to questionâ¯B is present in questionâ¯AâÂÂs thread.â If you have fully read the answer to How to ensure exclusive CPU availability for a running process? and tried everything that looks relevant to your question, say that.
â Scott
Feb 27 at 1:02
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
3
down vote
Under normal circumstances linux processes are not explicitly pinned to a given core, there is just no reason to do that.
You can manage process affinity using taskset or view which process runs on which CPU in the present instant using ps with the field 'psr'.
Check current CPU affinity of process 27395:
$ ps -o psr 27395
PSR
6
Check affinity list of process 27395:
$ taskset -pc 27395
pid 27395's current affinity list: 0-7
Set affinity of process 27395 to CPU 3
$ taskset -pc 3 27395
pid 27395's current affinity list: 0-7
pid 27395's new affinity list: 3
Check current CPU affinity of process 27395:
$ ps -o psr 27395
PSR
3
To check if any process is pinned to any CPU, you can loop through your process identifiers and run taskset -p against them:
$ for pid in $(ps -a -o pid=); do taskset -pc $pid 2>/dev/null; done
pid 1803's current affinity list: 0-7
pid 1812's current affinity list: 0-7
pid 1986's current affinity list: 0-7
pid 2027's current affinity list: 0-7
pid 2075's current affinity list: 0-7
pid 2083's current affinity list: 0-7
pid 2122's current affinity list: 0-7
pid 2180's current affinity list: 0-7
pid 2269's current affinity list: 0-7
pid 2289's current affinity list: 0-7
pid 2291's current affinity list: 0-7
pid 2295's current affinity list: 0-7
pid 2300's current affinity list: 0-7
pid 2302's current affinity list: 0-7
pid 3872's current affinity list: 0-7
pid 4339's current affinity list: 0-7
pid 7301's current affinity list: 0-7
pid 7302's current affinity list: 0-7
pid 7309's current affinity list: 0-7
pid 13972's current affinity list: 0-7
"there is just no reason to do that". Here is one reason: improve the performance of parallel programs.
â daruma
Feb 20 at 4:58
1
Aye, I've had to pin procs to a given CPU on occasion. Such as to reduce the context switching when multiple procs are competing for CPU time. Or to avoid dealing with NUMA.
â Patrick
Feb 20 at 5:19
I did say 'under normal circumstances'. Of course if you have a use case for it, then there's the solution :-) "Improve the performance of parallel programs" is a very generic goal. This is what the scheduler does and it does a pretty good job at it. You need to be very skilled or have a very specific situation to do better yourself. But you don't need to trust me, just give it a go.
â Pedro
Feb 20 at 8:16
add a comment |Â
up vote
0
down vote
First open terminal and do cat /proc/cpuinfo to list all cores. Core 0 = 1st core, Core 1 = 2nd core...
Then
CORENUM=0
ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM"
to see what has core 1 (replace 0 in CORENUM= with desired core number) assigned to it.
Thatpsformat does nothing on my system. It certainly doesn't list which CPUs a process is pinned to. Mypsman page doesn't even have acpufield documented (it has%cpu, but notcpu).
â Patrick
Feb 19 at 4:25
@Patrick Which distro do you have?
â Fido-X
Feb 19 at 4:28
1
root@localhost:~# CORENUM=0; ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM" 1008 0 - /usr/lib/colord/colord 1207 0 - /usr/lib/udisks2/udisksd 1666 0 - gdm-session-worker [pam/gdm-password] 1669 0 - /lib/systemd/systemd --user 1670 0 - (sd-pam) 1681 0 - /usr/bin/pulseaudio --daemonize=no 1687 0 - /usr/lib/gdm3/gdm-x-session --run-script /usr/bin/startlxde 1689 0 - /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/0/gdm/Xauthority -background none -noreset -keeptty -verbose 3
â Fido-X
Feb 19 at 4:29
There's more, but StackExchange says it's too long to paste it all. So i shortened it...
â Fido-X
Feb 19 at 4:29
processes of interest must have bin pinned to the given cores, not just currently running on the given core
â Jeff Schaller
Feb 20 at 3:40
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
Under normal circumstances linux processes are not explicitly pinned to a given core, there is just no reason to do that.
You can manage process affinity using taskset or view which process runs on which CPU in the present instant using ps with the field 'psr'.
Check current CPU affinity of process 27395:
$ ps -o psr 27395
PSR
6
Check affinity list of process 27395:
$ taskset -pc 27395
pid 27395's current affinity list: 0-7
Set affinity of process 27395 to CPU 3
$ taskset -pc 3 27395
pid 27395's current affinity list: 0-7
pid 27395's new affinity list: 3
Check current CPU affinity of process 27395:
$ ps -o psr 27395
PSR
3
To check if any process is pinned to any CPU, you can loop through your process identifiers and run taskset -p against them:
$ for pid in $(ps -a -o pid=); do taskset -pc $pid 2>/dev/null; done
pid 1803's current affinity list: 0-7
pid 1812's current affinity list: 0-7
pid 1986's current affinity list: 0-7
pid 2027's current affinity list: 0-7
pid 2075's current affinity list: 0-7
pid 2083's current affinity list: 0-7
pid 2122's current affinity list: 0-7
pid 2180's current affinity list: 0-7
pid 2269's current affinity list: 0-7
pid 2289's current affinity list: 0-7
pid 2291's current affinity list: 0-7
pid 2295's current affinity list: 0-7
pid 2300's current affinity list: 0-7
pid 2302's current affinity list: 0-7
pid 3872's current affinity list: 0-7
pid 4339's current affinity list: 0-7
pid 7301's current affinity list: 0-7
pid 7302's current affinity list: 0-7
pid 7309's current affinity list: 0-7
pid 13972's current affinity list: 0-7
"there is just no reason to do that". Here is one reason: improve the performance of parallel programs.
â daruma
Feb 20 at 4:58
1
Aye, I've had to pin procs to a given CPU on occasion. Such as to reduce the context switching when multiple procs are competing for CPU time. Or to avoid dealing with NUMA.
â Patrick
Feb 20 at 5:19
I did say 'under normal circumstances'. Of course if you have a use case for it, then there's the solution :-) "Improve the performance of parallel programs" is a very generic goal. This is what the scheduler does and it does a pretty good job at it. You need to be very skilled or have a very specific situation to do better yourself. But you don't need to trust me, just give it a go.
â Pedro
Feb 20 at 8:16
add a comment |Â
up vote
3
down vote
Under normal circumstances linux processes are not explicitly pinned to a given core, there is just no reason to do that.
You can manage process affinity using taskset or view which process runs on which CPU in the present instant using ps with the field 'psr'.
Check current CPU affinity of process 27395:
$ ps -o psr 27395
PSR
6
Check affinity list of process 27395:
$ taskset -pc 27395
pid 27395's current affinity list: 0-7
Set affinity of process 27395 to CPU 3
$ taskset -pc 3 27395
pid 27395's current affinity list: 0-7
pid 27395's new affinity list: 3
Check current CPU affinity of process 27395:
$ ps -o psr 27395
PSR
3
To check if any process is pinned to any CPU, you can loop through your process identifiers and run taskset -p against them:
$ for pid in $(ps -a -o pid=); do taskset -pc $pid 2>/dev/null; done
pid 1803's current affinity list: 0-7
pid 1812's current affinity list: 0-7
pid 1986's current affinity list: 0-7
pid 2027's current affinity list: 0-7
pid 2075's current affinity list: 0-7
pid 2083's current affinity list: 0-7
pid 2122's current affinity list: 0-7
pid 2180's current affinity list: 0-7
pid 2269's current affinity list: 0-7
pid 2289's current affinity list: 0-7
pid 2291's current affinity list: 0-7
pid 2295's current affinity list: 0-7
pid 2300's current affinity list: 0-7
pid 2302's current affinity list: 0-7
pid 3872's current affinity list: 0-7
pid 4339's current affinity list: 0-7
pid 7301's current affinity list: 0-7
pid 7302's current affinity list: 0-7
pid 7309's current affinity list: 0-7
pid 13972's current affinity list: 0-7
"there is just no reason to do that". Here is one reason: improve the performance of parallel programs.
â daruma
Feb 20 at 4:58
1
Aye, I've had to pin procs to a given CPU on occasion. Such as to reduce the context switching when multiple procs are competing for CPU time. Or to avoid dealing with NUMA.
â Patrick
Feb 20 at 5:19
I did say 'under normal circumstances'. Of course if you have a use case for it, then there's the solution :-) "Improve the performance of parallel programs" is a very generic goal. This is what the scheduler does and it does a pretty good job at it. You need to be very skilled or have a very specific situation to do better yourself. But you don't need to trust me, just give it a go.
â Pedro
Feb 20 at 8:16
add a comment |Â
up vote
3
down vote
up vote
3
down vote
Under normal circumstances linux processes are not explicitly pinned to a given core, there is just no reason to do that.
You can manage process affinity using taskset or view which process runs on which CPU in the present instant using ps with the field 'psr'.
Check current CPU affinity of process 27395:
$ ps -o psr 27395
PSR
6
Check affinity list of process 27395:
$ taskset -pc 27395
pid 27395's current affinity list: 0-7
Set affinity of process 27395 to CPU 3
$ taskset -pc 3 27395
pid 27395's current affinity list: 0-7
pid 27395's new affinity list: 3
Check current CPU affinity of process 27395:
$ ps -o psr 27395
PSR
3
To check if any process is pinned to any CPU, you can loop through your process identifiers and run taskset -p against them:
$ for pid in $(ps -a -o pid=); do taskset -pc $pid 2>/dev/null; done
pid 1803's current affinity list: 0-7
pid 1812's current affinity list: 0-7
pid 1986's current affinity list: 0-7
pid 2027's current affinity list: 0-7
pid 2075's current affinity list: 0-7
pid 2083's current affinity list: 0-7
pid 2122's current affinity list: 0-7
pid 2180's current affinity list: 0-7
pid 2269's current affinity list: 0-7
pid 2289's current affinity list: 0-7
pid 2291's current affinity list: 0-7
pid 2295's current affinity list: 0-7
pid 2300's current affinity list: 0-7
pid 2302's current affinity list: 0-7
pid 3872's current affinity list: 0-7
pid 4339's current affinity list: 0-7
pid 7301's current affinity list: 0-7
pid 7302's current affinity list: 0-7
pid 7309's current affinity list: 0-7
pid 13972's current affinity list: 0-7
Under normal circumstances linux processes are not explicitly pinned to a given core, there is just no reason to do that.
You can manage process affinity using taskset or view which process runs on which CPU in the present instant using ps with the field 'psr'.
Check current CPU affinity of process 27395:
$ ps -o psr 27395
PSR
6
Check affinity list of process 27395:
$ taskset -pc 27395
pid 27395's current affinity list: 0-7
Set affinity of process 27395 to CPU 3
$ taskset -pc 3 27395
pid 27395's current affinity list: 0-7
pid 27395's new affinity list: 3
Check current CPU affinity of process 27395:
$ ps -o psr 27395
PSR
3
To check if any process is pinned to any CPU, you can loop through your process identifiers and run taskset -p against them:
$ for pid in $(ps -a -o pid=); do taskset -pc $pid 2>/dev/null; done
pid 1803's current affinity list: 0-7
pid 1812's current affinity list: 0-7
pid 1986's current affinity list: 0-7
pid 2027's current affinity list: 0-7
pid 2075's current affinity list: 0-7
pid 2083's current affinity list: 0-7
pid 2122's current affinity list: 0-7
pid 2180's current affinity list: 0-7
pid 2269's current affinity list: 0-7
pid 2289's current affinity list: 0-7
pid 2291's current affinity list: 0-7
pid 2295's current affinity list: 0-7
pid 2300's current affinity list: 0-7
pid 2302's current affinity list: 0-7
pid 3872's current affinity list: 0-7
pid 4339's current affinity list: 0-7
pid 7301's current affinity list: 0-7
pid 7302's current affinity list: 0-7
pid 7309's current affinity list: 0-7
pid 13972's current affinity list: 0-7
answered Feb 19 at 8:23
Pedro
59429
59429
"there is just no reason to do that". Here is one reason: improve the performance of parallel programs.
â daruma
Feb 20 at 4:58
1
Aye, I've had to pin procs to a given CPU on occasion. Such as to reduce the context switching when multiple procs are competing for CPU time. Or to avoid dealing with NUMA.
â Patrick
Feb 20 at 5:19
I did say 'under normal circumstances'. Of course if you have a use case for it, then there's the solution :-) "Improve the performance of parallel programs" is a very generic goal. This is what the scheduler does and it does a pretty good job at it. You need to be very skilled or have a very specific situation to do better yourself. But you don't need to trust me, just give it a go.
â Pedro
Feb 20 at 8:16
add a comment |Â
"there is just no reason to do that". Here is one reason: improve the performance of parallel programs.
â daruma
Feb 20 at 4:58
1
Aye, I've had to pin procs to a given CPU on occasion. Such as to reduce the context switching when multiple procs are competing for CPU time. Or to avoid dealing with NUMA.
â Patrick
Feb 20 at 5:19
I did say 'under normal circumstances'. Of course if you have a use case for it, then there's the solution :-) "Improve the performance of parallel programs" is a very generic goal. This is what the scheduler does and it does a pretty good job at it. You need to be very skilled or have a very specific situation to do better yourself. But you don't need to trust me, just give it a go.
â Pedro
Feb 20 at 8:16
"there is just no reason to do that". Here is one reason: improve the performance of parallel programs.
â daruma
Feb 20 at 4:58
"there is just no reason to do that". Here is one reason: improve the performance of parallel programs.
â daruma
Feb 20 at 4:58
1
1
Aye, I've had to pin procs to a given CPU on occasion. Such as to reduce the context switching when multiple procs are competing for CPU time. Or to avoid dealing with NUMA.
â Patrick
Feb 20 at 5:19
Aye, I've had to pin procs to a given CPU on occasion. Such as to reduce the context switching when multiple procs are competing for CPU time. Or to avoid dealing with NUMA.
â Patrick
Feb 20 at 5:19
I did say 'under normal circumstances'. Of course if you have a use case for it, then there's the solution :-) "Improve the performance of parallel programs" is a very generic goal. This is what the scheduler does and it does a pretty good job at it. You need to be very skilled or have a very specific situation to do better yourself. But you don't need to trust me, just give it a go.
â Pedro
Feb 20 at 8:16
I did say 'under normal circumstances'. Of course if you have a use case for it, then there's the solution :-) "Improve the performance of parallel programs" is a very generic goal. This is what the scheduler does and it does a pretty good job at it. You need to be very skilled or have a very specific situation to do better yourself. But you don't need to trust me, just give it a go.
â Pedro
Feb 20 at 8:16
add a comment |Â
up vote
0
down vote
First open terminal and do cat /proc/cpuinfo to list all cores. Core 0 = 1st core, Core 1 = 2nd core...
Then
CORENUM=0
ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM"
to see what has core 1 (replace 0 in CORENUM= with desired core number) assigned to it.
Thatpsformat does nothing on my system. It certainly doesn't list which CPUs a process is pinned to. Mypsman page doesn't even have acpufield documented (it has%cpu, but notcpu).
â Patrick
Feb 19 at 4:25
@Patrick Which distro do you have?
â Fido-X
Feb 19 at 4:28
1
root@localhost:~# CORENUM=0; ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM" 1008 0 - /usr/lib/colord/colord 1207 0 - /usr/lib/udisks2/udisksd 1666 0 - gdm-session-worker [pam/gdm-password] 1669 0 - /lib/systemd/systemd --user 1670 0 - (sd-pam) 1681 0 - /usr/bin/pulseaudio --daemonize=no 1687 0 - /usr/lib/gdm3/gdm-x-session --run-script /usr/bin/startlxde 1689 0 - /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/0/gdm/Xauthority -background none -noreset -keeptty -verbose 3
â Fido-X
Feb 19 at 4:29
There's more, but StackExchange says it's too long to paste it all. So i shortened it...
â Fido-X
Feb 19 at 4:29
processes of interest must have bin pinned to the given cores, not just currently running on the given core
â Jeff Schaller
Feb 20 at 3:40
add a comment |Â
up vote
0
down vote
First open terminal and do cat /proc/cpuinfo to list all cores. Core 0 = 1st core, Core 1 = 2nd core...
Then
CORENUM=0
ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM"
to see what has core 1 (replace 0 in CORENUM= with desired core number) assigned to it.
Thatpsformat does nothing on my system. It certainly doesn't list which CPUs a process is pinned to. Mypsman page doesn't even have acpufield documented (it has%cpu, but notcpu).
â Patrick
Feb 19 at 4:25
@Patrick Which distro do you have?
â Fido-X
Feb 19 at 4:28
1
root@localhost:~# CORENUM=0; ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM" 1008 0 - /usr/lib/colord/colord 1207 0 - /usr/lib/udisks2/udisksd 1666 0 - gdm-session-worker [pam/gdm-password] 1669 0 - /lib/systemd/systemd --user 1670 0 - (sd-pam) 1681 0 - /usr/bin/pulseaudio --daemonize=no 1687 0 - /usr/lib/gdm3/gdm-x-session --run-script /usr/bin/startlxde 1689 0 - /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/0/gdm/Xauthority -background none -noreset -keeptty -verbose 3
â Fido-X
Feb 19 at 4:29
There's more, but StackExchange says it's too long to paste it all. So i shortened it...
â Fido-X
Feb 19 at 4:29
processes of interest must have bin pinned to the given cores, not just currently running on the given core
â Jeff Schaller
Feb 20 at 3:40
add a comment |Â
up vote
0
down vote
up vote
0
down vote
First open terminal and do cat /proc/cpuinfo to list all cores. Core 0 = 1st core, Core 1 = 2nd core...
Then
CORENUM=0
ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM"
to see what has core 1 (replace 0 in CORENUM= with desired core number) assigned to it.
First open terminal and do cat /proc/cpuinfo to list all cores. Core 0 = 1st core, Core 1 = 2nd core...
Then
CORENUM=0
ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM"
to see what has core 1 (replace 0 in CORENUM= with desired core number) assigned to it.
edited Feb 27 at 0:47
Tomasz
8,04052560
8,04052560
answered Feb 19 at 3:44
Fido-X
1225
1225
Thatpsformat does nothing on my system. It certainly doesn't list which CPUs a process is pinned to. Mypsman page doesn't even have acpufield documented (it has%cpu, but notcpu).
â Patrick
Feb 19 at 4:25
@Patrick Which distro do you have?
â Fido-X
Feb 19 at 4:28
1
root@localhost:~# CORENUM=0; ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM" 1008 0 - /usr/lib/colord/colord 1207 0 - /usr/lib/udisks2/udisksd 1666 0 - gdm-session-worker [pam/gdm-password] 1669 0 - /lib/systemd/systemd --user 1670 0 - (sd-pam) 1681 0 - /usr/bin/pulseaudio --daemonize=no 1687 0 - /usr/lib/gdm3/gdm-x-session --run-script /usr/bin/startlxde 1689 0 - /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/0/gdm/Xauthority -background none -noreset -keeptty -verbose 3
â Fido-X
Feb 19 at 4:29
There's more, but StackExchange says it's too long to paste it all. So i shortened it...
â Fido-X
Feb 19 at 4:29
processes of interest must have bin pinned to the given cores, not just currently running on the given core
â Jeff Schaller
Feb 20 at 3:40
add a comment |Â
Thatpsformat does nothing on my system. It certainly doesn't list which CPUs a process is pinned to. Mypsman page doesn't even have acpufield documented (it has%cpu, but notcpu).
â Patrick
Feb 19 at 4:25
@Patrick Which distro do you have?
â Fido-X
Feb 19 at 4:28
1
root@localhost:~# CORENUM=0; ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM" 1008 0 - /usr/lib/colord/colord 1207 0 - /usr/lib/udisks2/udisksd 1666 0 - gdm-session-worker [pam/gdm-password] 1669 0 - /lib/systemd/systemd --user 1670 0 - (sd-pam) 1681 0 - /usr/bin/pulseaudio --daemonize=no 1687 0 - /usr/lib/gdm3/gdm-x-session --run-script /usr/bin/startlxde 1689 0 - /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/0/gdm/Xauthority -background none -noreset -keeptty -verbose 3
â Fido-X
Feb 19 at 4:29
There's more, but StackExchange says it's too long to paste it all. So i shortened it...
â Fido-X
Feb 19 at 4:29
processes of interest must have bin pinned to the given cores, not just currently running on the given core
â Jeff Schaller
Feb 20 at 3:40
That
ps format does nothing on my system. It certainly doesn't list which CPUs a process is pinned to. My ps man page doesn't even have a cpu field documented (it has %cpu, but not cpu).â Patrick
Feb 19 at 4:25
That
ps format does nothing on my system. It certainly doesn't list which CPUs a process is pinned to. My ps man page doesn't even have a cpu field documented (it has %cpu, but not cpu).â Patrick
Feb 19 at 4:25
@Patrick Which distro do you have?
â Fido-X
Feb 19 at 4:28
@Patrick Which distro do you have?
â Fido-X
Feb 19 at 4:28
1
1
root@localhost:~# CORENUM=0; ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM" 1008 0 - /usr/lib/colord/colord 1207 0 - /usr/lib/udisks2/udisksd 1666 0 - gdm-session-worker [pam/gdm-password] 1669 0 - /lib/systemd/systemd --user 1670 0 - (sd-pam) 1681 0 - /usr/bin/pulseaudio --daemonize=no 1687 0 - /usr/lib/gdm3/gdm-x-session --run-script /usr/bin/startlxde 1689 0 - /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/0/gdm/Xauthority -background none -noreset -keeptty -verbose 3
â Fido-X
Feb 19 at 4:29
root@localhost:~# CORENUM=0; ps -e -o pid,psr,cpu,cmd | grep -E "^[[:space:]][[:digit:]]+[[:space:]]+$CORENUM" 1008 0 - /usr/lib/colord/colord 1207 0 - /usr/lib/udisks2/udisksd 1666 0 - gdm-session-worker [pam/gdm-password] 1669 0 - /lib/systemd/systemd --user 1670 0 - (sd-pam) 1681 0 - /usr/bin/pulseaudio --daemonize=no 1687 0 - /usr/lib/gdm3/gdm-x-session --run-script /usr/bin/startlxde 1689 0 - /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/0/gdm/Xauthority -background none -noreset -keeptty -verbose 3
â Fido-X
Feb 19 at 4:29
There's more, but StackExchange says it's too long to paste it all. So i shortened it...
â Fido-X
Feb 19 at 4:29
There's more, but StackExchange says it's too long to paste it all. So i shortened it...
â Fido-X
Feb 19 at 4:29
processes of interest must have bin pinned to the given cores, not just currently running on the given coreâ Jeff Schaller
Feb 20 at 3:40
processes of interest must have bin pinned to the given cores, not just currently running on the given coreâ Jeff Schaller
Feb 20 at 3:40
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f425065%2flinux-how-to-know-which-processes-are-pinned-to-which-core%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
see the
tasksetcommandâ Patrick
Feb 19 at 4:23
A somewhat controversial part of our system is that questions donâÂÂt have to be the same question to be duplicates.â All that is required is that the answer to questionâ¯B is present in questionâ¯AâÂÂs thread.â If you have fully read the answer to How to ensure exclusive CPU availability for a running process? and tried everything that looks relevant to your question, say that.
â Scott
Feb 27 at 1:02