[PD] Subprocess CPU core check

Christof Ressi info at christofressi.com
Fri Mar 20 18:41:22 CET 2020


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 at gmail.com 
> <mailto:czhenry at 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 at gmail.com
>     <mailto:langcsaba at 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 at iem.at <mailto:zmoelnig at 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 at revolwear.com
>     <mailto:abonnements at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>     >> UNSUBSCRIBE and account-management ->
>     https://lists.puredata.info/listinfo/pd-list
>     >
>     > _______________________________________________
>     > Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>     > UNSUBSCRIBE and account-management ->
>     https://lists.puredata.info/listinfo/pd-list
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200320/78adf47d/attachment.html>


More information about the Pd-list mailing list