[hdiethelm]

Fixes #4525

• hm2 eth back to polling: This increases the CPU load. It is beneficial for badly tuned systems. But it could be an issue if you have a 3. task with lower priority witch would be interrupted every 10us. Due to polling was active for a long time, it should be no issue.

• Fallback in case isolcpus is not set: After Xenomai4 Userspace + other fixes #3903, no CPU was assigned to the real-time threads and a warning is shown. This assumed all users set at least isolcpus as mentioned in https://linuxcnc.org/docs/html/install/latency-test.html#_tuning_preempt_rt_for_latency. However, it turned out, not assigning a CPU when isolcpus is not set results in worse latency. This restores the behavior from before, assigning the highest number CPU if isolcpus is not set.

The second part was merged in #4735

ToDo:

• Check if polling is really a good idea

[rene-dev]

I think it should be made adjustable, sometimes busy waiting can get better results.
there is a whole unmerged branch about this, which busywaits instead of sleeping for the whole thread.
master...busywait7#diff-f4794dcafb3969fe7062a59872501f5c41c21eeb8569879dd3302f17b153629aR272-R276

[hdiethelm]

My experience so far is, that as soon as you configured your machine the correct way, all this things make no difference any more. But I can test this branch on my PC.

So the best solution is automatic setup scrips and a proper doc. The scripts are coming together but it takes some time. I need to test all of this on different PC's.

This is how it looks on a well tuned Dell 5810 + 22 core E5-2699 v4 + Radeon RX 5500 + I210 Network card 15$ from china, no bios tweeks, just two scripts, done. I also need to do longer tests but this is what I have so far:

Load:

stress-ng --cpu 44 --vm 4
glxgears

latency-histogram

Hostmot2 read time: hal-histogram --minvalue 0 --binsize 0.5e-5 --nbins 200 hm2_7i96s.0.read.time

[rene-dev]

it did make a difference when I tested it back then. I can update the branch if you are interested.
there is another trick, which doesnt busywait all the time: wake up early, and busywait the rest.
did you know that you can use lstopo from the hwloc package to see which cpus share which caches?
https://docs.kernel.org/core-api/real-time/hardware.html#system-memory-and-cache

[hdiethelm]

Rebasing the full branch just to test busywait is probably a bit overkill. I will first finalize my RT scripts / doc and then I can also just check busywait by replacing the wait function with the one from the branch.

At least xenomai4 does that wake up early already and you can configure how much or autotune it. I have to see if you can set this also for PREEMT_RT or if you have to do it by hand. However, doing this will block other lower prio threads.

Thanks for the shared cache hint, isolating or even deactivating all CPU's that share one cache could help but will degrade the performance quite a bit, especially if no cores are left afterwards... ;-)