Apologies if this is documented somewhere, but I have not been able to find it.
Is there some setting either in Elk Audio OS or xenomai which is setting core affinity so that there is an even split between RT needs and “user land” needs? i.e. 2 cores each?
This seems to be what we are seeing when monitoring CPU performance on ElkOS 1.0. on a RPi4 when we compare the output of evl ps -t and proc/stat.
It’s probably quite badly documented, if it even is documented 
. But essentially multithreaded audio processing on EVL is done using the worker pool from twine. Sushi is using that worker pool for processing if run with the -m argument.
If you want to use isolated cpus for audio processing, that is done through the file “/sys/devices/system/cpu/isolated” which is read by twine, which can then allocate workers to the isolated cores. That part is not documented i think, I’m unsure if that is even enabled for the RPi image.
No problem. And thanks for the info.
We’ve just started getting into trying to access how over budget we are in some parts of the project. So it’s possible some of our “home grown” tooling is giving us a false read.
I also wondered if I’d regret asking this question as this may be common knowledge in how the image is setup and RT kernels work…
However, it appears that two of the cores on the Pi4 are not being used at all until we fire raspa tasks off.
That in of itself kind of makes sense, and the isolation is nice. But I had assumed that any task could use any core and our problem would be balancing that.
It seems, unless we’ve broken something with our hacking (very possible), that what we have right now is two cores ring-fenced for audio and two cores for general tasks.
I should add actually…
We experimented with sushi -r --multicore-processing=N
On the 2 core setting it used one of the cores that seems to be allocated for audio. We tried 4 and it then used both of them.
This is from results coming back from evl ps -t, not just our own tooling.
And the observation is anecdotal as we weren’t particularly stressing anything, just eyeballing stats.
But this has us confused right now.
Seems core 2 and 3 are “isolated” when I cat that file. So that may well explain this.
cat /proc/cmdline contains…
isolcpus=2-3 evl.oobcpus=2-3
Many thanks for looking, I don’t have a board on hand atm. Then it is indeed setup to run audio threads (EVL threads) on core 2 & 3 and normal posix threads on 0 & 1.
Though I would have though that running sushi with -m 2 should start 2 evl threads on cores 2 & 3. Not some other combination.
I will try to do some testing myself next week and get back to you
Hi Stephen. I did get some time to test this today. I used the 1.0 image from github. Releases · elk-audio/elk-pi · GitHub
Core allocation seems to work correctly for me. By default cpu 2 and 3 are set as isolated and evl threads are configured to run on those cores. Running sushi with -m2 creates 2 worker threads on core 2 and 3, as expected. I verified this with evl ps -t. Running sushi with -m4 though creates 4 worker threads, but all of them allocated to core 2 and 3. So in this case -m4 will not give better performance than -m2, in fact slightly worse due to the added overhead of thread switching.
I think at the very least we should find some way of warning the user when multiple workers end up on the same cpu. But for optimal performance you should not run sushi with more cpus than you have isolated in the system.
Thanks very much for verifying that @Gustav.
We’ve got a bit deeper into chaining generators together so we are starting to see higher core usage overall now. And it does seem to be spreading work around the cores as we’d expect.
I’m curious if there is a simple way to allocate a plugin to a core in the configuration file? So if your configuration opens a couple plugins, can you ensure that each runs on a separate core?
Welcome, Peter!
I don’t know the answer to your specific question, but we’ve been thinking about how to prioritise “user land” work vs “audio work” in our prototype, and I’ve spent a fair amount of time pouring over these docs musing on the possibilities of core affinity / thread affinity settings.
Hi peter and welcome to the forums. At the moment, no. If sushi runs in multicore mode, cores are allocated to audio tracks in a round robin scheme. So putting 2 plugins on 2 adjacent tracks will in that case allocate them to different cores.
Though more detailed control of this is something that we’re looking into for a future version of sushi.