[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