5

What I'm trying to implement is to run a python script on it's own core on Raspberry Pi 2 with Debian. One can use taskset to bind a process to particular core. But I need this core to be free of OS's and other processes' load at the same time. How can I do it?

2
  • Perhaps also set it to realtime priority? May 30, 2016 at 6:33
  • @Leonidas I expanded my answer with some test resutls. Check it out. May 30, 2016 at 19:16

2 Answers 2

5

This whole thread should be useful.

I would look for a way to limit the 'init' process to running on cpu 1.

In general case the last words should be "running on all CPUs but 1". I guess one can use some kernel parameters; irqaffinity, isolcpus look promising.


EDIT:

About isolcpus in kernel parameters documentation:

This option is the preferred way to isolate CPUs. The alternative -- manually setting the CPU mask of all tasks in the system -- can cause problems and suboptimal load balancer performance.

I did some tests. Results:

  • Kernel parameter isolcpus is the one you may use to limit the init process and isolate CPU(s).

  • It seemed to me that kernel parameter irqaffinity did not affect isolated CPU(s). You probably don't need this parameter.

  • When I isolated CPU0 it didn't go completely idle. Is that system or hardware requirement to do some computation with it despite isolation? – I don't know.

  • When I isolated CPU1 or CPU7 it was solid as idle as a rock.

To isolate CPU1 add isolcpus=1 in your grub.cfg, like this:
linux /vmlinuz-(…all your current parameters here…) isolcpus=1


ORIGINAL ANSWER CONTINUES:

Alternatively, after the system has started, you can re-assign the affinity of all currently running processes, but that seems less elegant.

I agree it seems less elegant, yet it may work good enough (EDIT: it can cause problems and suboptimal load balancer performance, as stated above). There is quick and dirty one-liner that works in my Debian:

sudo bash -c 'cd /proc ; for i in [1-9]* ; do taskset -a -p fffffffe $i ; done'

I got errors for some pids, nevertheless htop shows that one core is virtually idle after that. Of course you have to run your script later, exclude it somehow or simply reassign:

taskset -a -p 1 PID

I expect you won't need to repeat said one-liner to cover new processes since CPU affinity is inherited.

3

With package Cpuset:

# cset shield -c 42 -k on

to reserve CPU #42 for your task (you can reserve a group of CPUs), then

# cset shield -e your_script

to start your_script on your reserved CPUs. (See also options --user and --group.)

When you're done, release CPUs ("reset the shield") with:

# cset shield -r

There is much, much more to this tool. E.g., attaching a previously running process to the reserved CPU:

# cset shield -s -p <PID> --threads

Command-line help:

# cset help

Online help/tutorial

2
  • Looks promising. Can you expand your answer and post a command to release the reservation and return to default state? May 30, 2016 at 19:28
  • @KamilMaciorowski: do you have any feedback to provide about the commands I added on your request?
    – L. Levrel
    Jun 10, 2016 at 17:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .