Skip to content

Fix #4734 rtapi_app: Assign highest number CPU if no isolated CPU was found - #4735

Merged
grandixximo merged 1 commit into
LinuxCNC:masterfrom
hdiethelm:fix_4734
Oct 30, 2026
Merged

grandixximo merged 1 commit into
LinuxCNC:masterfrom
hdiethelm:fix_4734

Conversation

@hdiethelm

@hdiethelm hdiethelm commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor

Fallback in case isolcpus is not set: After #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. And it fails tests/threads.0 sporadically. This restores the behavior from before, assigning the highest number CPU if isolcpus is not set.

The reason sched_getaffinity() is used and not long ncpus = sysconf(_SC_NPROCESSORS_CONF) is that on linux, you can offline CPU's or disable SMT on the kernel command line which could result in an issue. sched_getaffinity() returns the processor's the thread can run on and uses the highest of these. However, it will exclude isolated CPU's if parse_cpu_list() fails to detect the isolated CPU's.

Fixes #4734
Partially fixes #4525

Comment thread src/rtapi/uspace_rtapi_app.cc Resolved
@rene-dev

Copy link
Copy Markdown
Member

Highest number could choose an efficiency core: https://stackoverflow.com/a/79238548

If isolcpus is not used, not assigning a CPU to the thread resulted in
higher latency and sporadic failures of tests/threads.0
@hdiethelm

Copy link
Copy Markdown
Contributor Author

Highest number could choose an efficiency core: https://stackoverflow.com/a/79238548

Not could, it will for sure. This also came to my mind while working on the kernel command line generator. However, I have no way to check it if I fix it. Do you have such a PC so you can test this?

@hdiethelm

Copy link
Copy Markdown
Contributor Author

Hmm, on the other hand, using the efficiency cores could be better or worse for latency. More GHz does not mean automatically less latency. This needs testing. But I can't, I don't have such a PC.

isolcpus should anyway always be set. This PR is mostly to not brake cases where it is not done and restores the old behavior.

However, for the kernel command line tool I am working on, it would be good to take the big/little issue into account. Right now, it will fail in this case.

@grandixximo
grandixximo merged commit 2ac2c1d into LinuxCNC:master Oct 30, 2026
19 checks passed
@grandixximo

grandixximo commented Oct 30, 2026 •

Copy link
Copy Markdown
Contributor

Merged this, and the follow up can continue on #4719

@rmu75

rmu75 commented Oct 30, 2026

Copy link
Copy Markdown
Collaborator

Intel 12th generation+ efficiency cores should have performance comparable to skylake (intel core 6th generation), so are more than powerful enough. I don't think that the microarchitecture will have noticeable impacts on latency, but things like numa-architecture, powersaving, speed governor etc... could behave differently than on more uniform CPUs and have an impact.

I can test on laptop hardware with Alder Lake 12th generation i5-1235U with 2 performance cores (4 threads) and 8 efficiency cores (8 threads).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

uspace: realtime threads are no longer pinned to one CPU without isolcpus, so HAL threads run concurrently hm2_eth read timeout

4 participants