Configure htop to show process CPU:

https://unix.stackexchange.com/a/349909

Cpu and affinity in C++ (also advice about lstopo):

https://eli.thegreenplace.net/2016/c11-threads-affinity-and-hyperthreading/#id2

View threads in htop:

http://ask.xmodulo.com/view-threads-process-linux.html

Check isolated cpus:

/sys/devices/system/cpu/isolated

https://unix.stackexchange.com/a/338372

Isolating CPU with isolcpus:

sudo nano /etc/default/grub

add isolcpus=[cpuid] to GRUB_CMDLINE_LINUX_DEFAULT and save, then:

sudo grub-mkconfig -o /boot/grub/grub.cfg

https://www.suse.com/support/kb/doc/?id=7009596 https://wiki.archlinux.org/index.php/kernel_parameters

Isolating CPU, alternative method with cpuset and cgroups:

http://linuxrealtime.org/index.php/Improving_the_Real-Time_Properties#Isolating_CPUs

Isolation and IRQs

Mention of isolcpus also working with IRQ (is it true for antergos/arch?):

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/interrupt_and_process_binding

Tuning IRQs:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-cpu-irq

You can check /proc/interrupts to see whether isolated CPU is used for IRQs or not.

Is there ar IRQ for audio i/o? If yes, how is that affected by isolation? Should we schedule those IRQs on the isolated core? (On its own isolated core if you have more than two cores?)

Antergos doesn't have irqbalance, so it's a matter of setting the affinity for the IRQs to the desired CPUs. there is /proc/irq/default_smp_affinity that should allow setting the affinity of all IRQs (and you can then set the one you want on a single one or a few of them).

https://www.kernel.org/doc/Documentation/IRQ-affinity.txt

I couldn't make it work, but in theory you can also iterate on all IRQs in proc/irq and set the affinity with # echo {hex-mask} > /proc/irq/{num}/smp_affinity. This works, as you can see by cating proc/interrupts.

I noticed that moving the IRQ for the audio device to the CPU hogged by my cpu-hog process doesn't lead to glitches. Which makes sense considering that the IRQs are supposed to always immediately interrupt any other activity in progress on the CPU.

Tried adding a parameter for the sine frequency to be changed from the main thread, both with locks and with atomic load/store. We have issues only when we sleep for ~5 ms in the main thread after taking the lock. Let's see what happens when lowering the priority of the main thread. Setting a lower priority (actually a low-priority scheduler) for the main thread leads to glitches when using the lock with just 1ms of sleep. The glitch is not there if the priority of the main thread is regular. So this is an indication of how priority inversion can be damaging when the scheduler is not friendly to our main thread.

Also, let's see how to isolate CPUs at runtime without having to add a boot param:

• Unplugging the CPU with echo 0 > /sys/devices/system/cpu/cpu1/online won't work, the CPU will not be available at all
• With cpuset it may somehow work, but it's complex and not perfect. Isolating a cpu in a cpuset makes it unavailable to a process belonging to another cpuset. So we need to create a cpuset with all the CPUS, run our app on that cpuset and then do some other things to ensure separation of the audio thread from the rest. And, some kernel threads cannot be moved away from the CPU we want to isolate.
• Apparently the best way is isolcpus boot parameter

CPUSET quick reference

https://stackoverflow.com/questions/11111852/how-to-shield-a-cpu-from-the-linux-scheduler-prevent-it-scheduling-threads-onto

Easiest way to create two sets:

cset shield --cpu 1,3
cset shield --kthread on
cset shield --reset

Pro:

cset set --cpu=0-3 --mem=0 --set=audio
cset proc --move --fromset=root --toset=audio
sudo cset set --cpu=0,2 --mem=0 --set=normal
cset proc --move --fromset=audio --toset=normal
cset set --list
cset proc --kthread --fromset=root --toset=normal
cset proc --kthread --fromset=root --toset=normal --force