Dear list, how can I check if my subprocess really runs on a different core than the main pd instance.
Best, Popesz
- Csaba Láng langcsaba@gmail.com [2020-03-04 23:32]:
Dear list, how can I check if my subprocess really runs on a different core than the main pd instance.
Telling about your operating system could be a first step.
True, my apologies. Ubuntu 19.04 Pd 0.50-0
On Wed, 4 Mar 2020 at 23:37, Peter P. peterparker@fastmail.com wrote:
- Csaba Láng langcsaba@gmail.com [2020-03-04 23:32]:
Dear list, how can I check if my subprocess really runs on a different core than the main pd instance.
Telling about your operating system could be a first step.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Use this command in a shell: top
https://en.m.wikipedia.org/wiki/Top_%28software%29?wprov=sfla1
The parent process will have the lowest pid. (The child processes spawn afterwards.)
On Wed, Mar 4, 2020, 2:40 PM Csaba Láng langcsaba@gmail.com wrote:
True, my apologies. Ubuntu 19.04 Pd 0.50-0
On Wed, 4 Mar 2020 at 23:37, Peter P. peterparker@fastmail.com wrote:
- Csaba Láng langcsaba@gmail.com [2020-03-04 23:32]:
Dear list, how can I check if my subprocess really runs on a different core than
the
main pd instance.
Telling about your operating system could be a first step.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thanks Andrew,
that's cool but it still does not prove me that it runs on a different core.
On Thu, Mar 5, 2020 at 12:00 AM Andrew Lyons tstexture@gmail.com wrote:
Use this command in a shell: top
https://en.m.wikipedia.org/wiki/Top_%28software%29?wprov=sfla1
The parent process will have the lowest pid. (The child processes spawn afterwards.)
On Wed, Mar 4, 2020, 2:40 PM Csaba Láng langcsaba@gmail.com wrote:
True, my apologies. Ubuntu 19.04 Pd 0.50-0
On Wed, 4 Mar 2020 at 23:37, Peter P. peterparker@fastmail.com wrote:
- Csaba Láng langcsaba@gmail.com [2020-03-04 23:32]:
Dear list, how can I check if my subprocess really runs on a different core than
the
main pd instance.
Telling about your operating system could be a first step.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
- Csaba Láng langcsaba@gmail.com [2020-03-05 09:08]:
Thanks Andrew,
that's cool but it still does not prove me that it runs on a different core.
A quick startpage.com search https://www.startpage.com/do/search?cat=web&language=english&query=s... yielded these https://unix.stackexchange.com/questions/349908/how-to-get-all-processes-run... https://stackoverflow.com/questions/8032372/how-can-i-see-which-cpu-core-a-t... https://serverfault.com/questions/836922/how-to-get-all-processes-running-on... (untested)
From what I know this is entirely under control of the system load balancing. So if the two Pd instances would run on the same core there would either be something seriously broken on your system, or you have other, even more CPU hungry processes running which are maxing out the other cores so that the system concludes that it's the best to have the two Pd instances running on the same core. A glance at the System Monitor CPU history graph should give you an idea.
m.
On 04.03.20 23:38, Csaba Láng wrote:
True, my apologies. Ubuntu 19.04 Pd 0.50-0
On Wed, 4 Mar 2020 at 23:37, Peter P. <peterparker@fastmail.com mailto:peterparker@fastmail.com> wrote:
* Csaba Láng <langcsaba@gmail.com <mailto:langcsaba@gmail.com>> [2020-03-04 23:32]: > Dear list, > how can I check if my subprocess really runs on a different core than the > main pd instance. Telling about your operating system could be a first step. _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Thu, Mar 5, 2020 at 4:14 AM Max abonnements@revolwear.com wrote:
From what I know this is entirely under control of the system load balancing. So if the two Pd instances would run on the same core there would either be something seriously broken on your system, or you have other, even more CPU hungry processes running which are maxing out the other cores so that the system concludes that it's the best to have the two Pd instances running on the same core. A glance at the System Monitor CPU history graph should give you an idea.
m.
you also have a few tools help you reduce/eliminate resource contention
The first is "nice" or "renice". You can lower the priority of the process that is less important. Both will be scheduled by the kernel, but you will reduce resource contention that affects your important processes.
Second, you can bind processes to certain CPUs. This is called "CPU affinity" and it's controlled by the linux command "taskset". This looks like a fine explanation: https://www.howtoforge.com/linux-taskset-command/ "cpuset" is a similar tool. It's been a while since I've dealt with "cpuset"s, so I can't tell the difference between "taskset" or "cpuset" right now
Chuck
On 04.03.20 23:38, Csaba Láng wrote:
True, my apologies. Ubuntu 19.04 Pd 0.50-0
On Wed, 4 Mar 2020 at 23:37, Peter P. <peterparker@fastmail.com mailto:peterparker@fastmail.com> wrote:
* Csaba Láng <langcsaba@gmail.com <mailto:langcsaba@gmail.com>> [2020-03-04 23:32]: > Dear list, > how can I check if my subprocess really runs on a different core than the > main pd instance. Telling about your operating system could be a first step. _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 3/5/20 10:48 PM, Charles Z Henry wrote:
On Thu, Mar 5, 2020 at 4:14 AM Max abonnements@revolwear.com wrote:
A glance at the System Monitor CPU history graph should give you an idea.
i usually use 'htop', which is a much improved version of top which also (among verious other interesting things) gives you the CPU of a process.
Second, you can bind processes to certain CPUs. This is called "CPU affinity" and it's controlled by the linux command "taskset". This looks like a fine explanation
but keep in mind that the people who designed the muticore scheduling algorithms most likely will have a better idea of how to ideally distribute multiple processes onto multiple CPUs.
gmsdr IOhannes
Dear list, I am getting closer to the solution of binding process to a certain core with taskset. e.g. taskset 0xa gedit will bind the gedit to the tenth core.
Now the problem is that I cannot identify the subprocess by its name as it will be pd too, and the PID will be always different so cannot use that number too. What would be the logical solution for starting the subprocess from pd with the taskedit command?
Thanks in advance for any help,
Popesz
On Thu, Mar 5, 2020 at 11:14 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
On 3/5/20 10:48 PM, Charles Z Henry wrote:
On Thu, Mar 5, 2020 at 4:14 AM Max abonnements@revolwear.com wrote:
A glance at the System Monitor CPU history graph should give you an
idea.
i usually use 'htop', which is a much improved version of top which also (among verious other interesting things) gives you the CPU of a process.
Second, you can bind processes to certain CPUs. This is called "CPU affinity" and it's controlled by the linux command "taskset". This looks like a fine explanation
but keep in mind that the people who designed the muticore scheduling algorithms most likely will have a better idea of how to ideally distribute multiple processes onto multiple CPUs.
gmsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Popesz,
Are you using [ggee/shell] ?
Here's an example that works on my linux machine
[taskset -c 2 $_ -noaudio >/dev/null & P=$! && echo $P && wait $P( | [ggee/shell] | [f ] ///the PID
When I run that command, $_ is a bash variable (see [env( - [shell] - [print] for full environment) that has the full path to the pd binary in use. You may have to replace "$_" with something more appropriate to your system I added -noaudio, because my first pd process is handling audio I/O. I don't need stdout from pd itself, so I added ">/dev/null". The process shows up in top or htop with those arguments included. You could distinguish between your processes by some environment variable or set of options to pd in the command. "& P=$! " launches pd into the background and records a variable P for its PID. There may be other ways of doing this. "&& echo $P && wait $P" causes the shell started by [shell] to output the PID to stdout (the left outlet). Without "wait $P", [shell] outputs a bang from its right outlet immediately. Using "wait $P" allows [shell] to maintain the status of the process, and it outputs a bang when the process ends.
Using htop, I see that the process starts and runs on CPU "3". Taskset must use a CPU numbering that starts at 0, and htop counts CPU's from 1.
Chuck
On Fri, Mar 20, 2020 at 10:23 AM Csaba Láng langcsaba@gmail.com wrote:
Dear list, I am getting closer to the solution of binding process to a certain core with taskset. e.g. taskset 0xa gedit will bind the gedit to the tenth core.
Now the problem is that I cannot identify the subprocess by its name as it will be pd too, and the PID will be always different so cannot use that number too. What would be the logical solution for starting the subprocess from pd with the taskedit command?
Thanks in advance for any help,
Popesz
On Thu, Mar 5, 2020 at 11:14 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
On 3/5/20 10:48 PM, Charles Z Henry wrote:
On Thu, Mar 5, 2020 at 4:14 AM Max abonnements@revolwear.com wrote:
A glance at the System Monitor CPU history graph should give you an idea.
i usually use 'htop', which is a much improved version of top which also (among verious other interesting things) gives you the CPU of a process.
Second, you can bind processes to certain CPUs. This is called "CPU affinity" and it's controlled by the linux command "taskset". This looks like a fine explanation
but keep in mind that the people who designed the muticore scheduling algorithms most likely will have a better idea of how to ideally distribute multiple processes onto multiple CPUs.
gmsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Chuck,
naturally i use [shell]. Your advice sounds like the ultimate solution. Now the same I have to make for the rest of the cores to keep the main Pd out of the core where the subprocess is bound.
Thanks a lot,
Popesz
On Fri, Mar 20, 2020 at 6:03 PM Charles Z Henry czhenry@gmail.com wrote:
Hi Popesz,
Are you using [ggee/shell] ?
Here's an example that works on my linux machine
[taskset -c 2 $_ -noaudio >/dev/null & P=$! && echo $P && wait $P( | [ggee/shell] | [f ] ///the PID
When I run that command, $_ is a bash variable (see [env( - [shell] - [print] for full environment) that has the full path to the pd binary in use. You may have to replace "$_" with something more appropriate to your system I added -noaudio, because my first pd process is handling audio I/O. I don't need stdout from pd itself, so I added ">/dev/null". The process shows up in top or htop with those arguments included. You could distinguish between your processes by some environment variable or set of options to pd in the command. "& P=$! " launches pd into the background and records a variable P for its PID. There may be other ways of doing this. "&& echo $P && wait $P" causes the shell started by [shell] to output the PID to stdout (the left outlet). Without "wait $P", [shell] outputs a bang from its right outlet immediately. Using "wait $P" allows [shell] to maintain the status of the process, and it outputs a bang when the process ends.
Using htop, I see that the process starts and runs on CPU "3". Taskset must use a CPU numbering that starts at 0, and htop counts CPU's from 1.
Chuck
On Fri, Mar 20, 2020 at 10:23 AM Csaba Láng langcsaba@gmail.com wrote:
Dear list, I am getting closer to the solution of binding process to a certain core
with taskset.
e.g. taskset 0xa gedit will bind the gedit to the tenth core.
Now the problem is that I cannot identify the subprocess by its name as
it will be pd too, and the PID will be always different so cannot use that number too.
What would be the logical solution for starting the subprocess from pd
with the taskedit command?
Thanks in advance for any help,
Popesz
On Thu, Mar 5, 2020 at 11:14 PM IOhannes m zmölnig zmoelnig@iem.at
wrote:
On 3/5/20 10:48 PM, Charles Z Henry wrote:
On Thu, Mar 5, 2020 at 4:14 AM Max abonnements@revolwear.com wrote:
A glance at the System Monitor CPU history graph should give you an
idea.
i usually use 'htop', which is a much improved version of top which also (among verious other interesting things) gives you the CPU of a process.
Second, you can bind processes to certain CPUs. This is called "CPU affinity" and it's controlled by the linux command "taskset". This looks like a fine explanation
but keep in mind that the people who designed the muticore scheduling algorithms most likely will have a better idea of how to ideally distribute multiple processes onto multiple CPUs.
gmsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
For a completely different solution: you could write an external which pins the current thread to a specific core with a message. Then you just have an instance of [threadpin] in each (sub)process and set the desired core via a startup message like 'pd -send ";cpu 1"'.
On the other hand, this could actually be a new startup flag for Pd, e.g. "pd -cpu 1".
Christof
On 20.03.2020 18:26, Csaba Láng wrote:
Chuck,
naturally i use [shell]. Your advice sounds like the ultimate solution. Now the same I have to make for the rest of the cores to keep the main Pd out of the core where the subprocess is bound.
Thanks a lot,
Popesz
On Fri, Mar 20, 2020 at 6:03 PM Charles Z Henry <czhenry@gmail.com mailto:czhenry@gmail.com> wrote:
Hi Popesz, Are you using [ggee/shell] ? Here's an example that works on my linux machine [taskset -c 2 $_ -noaudio >/dev/null & P=$! && echo $P && wait $P( | [ggee/shell] | [f ] ///the PID When I run that command, $_ is a bash variable (see [env( - [shell] - [print] for full environment) that has the full path to the pd binary in use. You may have to replace "$_" with something more appropriate to your system I added -noaudio, because my first pd process is handling audio I/O. I don't need stdout from pd itself, so I added ">/dev/null". The process shows up in top or htop with those arguments included. You could distinguish between your processes by some environment variable or set of options to pd in the command. "& P=$! " launches pd into the background and records a variable P for its PID. There may be other ways of doing this. "&& echo $P && wait $P" causes the shell started by [shell] to output the PID to stdout (the left outlet). Without "wait $P", [shell] outputs a bang from its right outlet immediately. Using "wait $P" allows [shell] to maintain the status of the process, and it outputs a bang when the process ends. Using htop, I see that the process starts and runs on CPU "3". Taskset must use a CPU numbering that starts at 0, and htop counts CPU's from 1. Chuck On Fri, Mar 20, 2020 at 10:23 AM Csaba Láng <langcsaba@gmail.com <mailto:langcsaba@gmail.com>> wrote: > > Dear list, > I am getting closer to the solution of binding process to a certain core with taskset. > e.g. taskset 0xa gedit will bind the gedit to the tenth core. > > Now the problem is that I cannot identify the subprocess by its name as it will be pd too, and the PID will be always different so cannot use that number too. > What would be the logical solution for starting the subprocess from pd with the taskedit command? > > Thanks in advance for any help, > > Popesz > > On Thu, Mar 5, 2020 at 11:14 PM IOhannes m zmölnig <zmoelnig@iem.at <mailto:zmoelnig@iem.at>> wrote: >> >> On 3/5/20 10:48 PM, Charles Z Henry wrote: >> > On Thu, Mar 5, 2020 at 4:14 AM Max <abonnements@revolwear.com <mailto:abonnements@revolwear.com>> wrote: >> >> >> >> A glance at the System Monitor CPU history graph should give you an idea. >> >> >> >> i usually use 'htop', which is a much improved version of top which also >> (among verious other interesting things) gives you the CPU of a process. >> >> > >> > Second, you can bind processes to certain CPUs. This is called "CPU >> > affinity" and it's controlled by the linux command "taskset". This >> > looks like a fine explanation >> >> >> but keep in mind that the people who designed the muticore scheduling >> algorithms most likely will have a better idea of how to ideally >> distribute multiple processes onto multiple CPUs. >> >> gmsdr >> IOhannes >> >> _______________________________________________ >> Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Andrew Lyons -
Charles Z Henry -
Christof Ressi -
Csaba Láng -
IOhannes m zmölnig -
Max -
Peter P.