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












2















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).










share|improve this question

























  • see the taskset command

    – Patrick
    Feb 19 '18 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 '18 at 1:02
















2















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).










share|improve this question

























  • see the taskset command

    – Patrick
    Feb 19 '18 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 '18 at 1:02














2












2








2








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).










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 27 '18 at 0:16







daruma

















asked Feb 19 '18 at 2:59









darumadaruma

476




476













  • see the taskset command

    – Patrick
    Feb 19 '18 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 '18 at 1:02



















  • see the taskset command

    – Patrick
    Feb 19 '18 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 '18 at 1:02

















see the taskset command

– Patrick
Feb 19 '18 at 4:23





see the taskset command

– Patrick
Feb 19 '18 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 '18 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 '18 at 1:02










3 Answers
3






active

oldest

votes


















4














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





share|improve this answer
























  • "there is just no reason to do that". Here is one reason: improve the performance of parallel programs.

    – daruma
    Feb 20 '18 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 '18 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 '18 at 8:16





















0














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.






share|improve this answer


























  • 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 '18 at 4:25













  • @Patrick Which distro do you have?

    – Fido-X
    Feb 19 '18 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 '18 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 '18 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 '18 at 3:40



















0














Answer to myself:
hwloc-bind from Linux (and homebrew for Macs) package hwloc.
Cf. https://www.open-mpi.org/projects/hwloc/tutorials/20130115-ComPAS-hwloc-tutorial.pdf for some doc.






share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    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















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    4














    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





    share|improve this answer
























    • "there is just no reason to do that". Here is one reason: improve the performance of parallel programs.

      – daruma
      Feb 20 '18 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 '18 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 '18 at 8:16


















    4














    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





    share|improve this answer
























    • "there is just no reason to do that". Here is one reason: improve the performance of parallel programs.

      – daruma
      Feb 20 '18 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 '18 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 '18 at 8:16
















    4












    4








    4







    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





    share|improve this answer













    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






    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Feb 19 '18 at 8:23









    PedroPedro

    62929




    62929













    • "there is just no reason to do that". Here is one reason: improve the performance of parallel programs.

      – daruma
      Feb 20 '18 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 '18 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 '18 at 8:16





















    • "there is just no reason to do that". Here is one reason: improve the performance of parallel programs.

      – daruma
      Feb 20 '18 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 '18 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 '18 at 8:16



















    "there is just no reason to do that". Here is one reason: improve the performance of parallel programs.

    – daruma
    Feb 20 '18 at 4:58







    "there is just no reason to do that". Here is one reason: improve the performance of parallel programs.

    – daruma
    Feb 20 '18 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 '18 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 '18 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 '18 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 '18 at 8:16















    0














    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.






    share|improve this answer


























    • 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 '18 at 4:25













    • @Patrick Which distro do you have?

      – Fido-X
      Feb 19 '18 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 '18 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 '18 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 '18 at 3:40
















    0














    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.






    share|improve this answer


























    • 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 '18 at 4:25













    • @Patrick Which distro do you have?

      – Fido-X
      Feb 19 '18 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 '18 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 '18 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 '18 at 3:40














    0












    0








    0







    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.






    share|improve this answer















    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Feb 27 '18 at 0:47









    Tomasz

    9,39852965




    9,39852965










    answered Feb 19 '18 at 3:44









    Fido-XFido-X

    1225




    1225













    • 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 '18 at 4:25













    • @Patrick Which distro do you have?

      – Fido-X
      Feb 19 '18 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 '18 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 '18 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 '18 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 '18 at 4:25













    • @Patrick Which distro do you have?

      – Fido-X
      Feb 19 '18 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 '18 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 '18 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 '18 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 '18 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 '18 at 4:25















    @Patrick Which distro do you have?

    – Fido-X
    Feb 19 '18 at 4:28





    @Patrick Which distro do you have?

    – Fido-X
    Feb 19 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 at 3:40











    0














    Answer to myself:
    hwloc-bind from Linux (and homebrew for Macs) package hwloc.
    Cf. https://www.open-mpi.org/projects/hwloc/tutorials/20130115-ComPAS-hwloc-tutorial.pdf for some doc.






    share|improve this answer




























      0














      Answer to myself:
      hwloc-bind from Linux (and homebrew for Macs) package hwloc.
      Cf. https://www.open-mpi.org/projects/hwloc/tutorials/20130115-ComPAS-hwloc-tutorial.pdf for some doc.






      share|improve this answer


























        0












        0








        0







        Answer to myself:
        hwloc-bind from Linux (and homebrew for Macs) package hwloc.
        Cf. https://www.open-mpi.org/projects/hwloc/tutorials/20130115-ComPAS-hwloc-tutorial.pdf for some doc.






        share|improve this answer













        Answer to myself:
        hwloc-bind from Linux (and homebrew for Macs) package hwloc.
        Cf. https://www.open-mpi.org/projects/hwloc/tutorials/20130115-ComPAS-hwloc-tutorial.pdf for some doc.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 14 mins ago









        darumadaruma

        476




        476






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            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















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Histoire des bourses de valeurs

            Why is there Russian traffic in my log files?

            Rename multiple files to decrement number in file name?