Open bymoz089 opened 1 year ago
Hi @bymoz089, thanks for this interesting contribution. I understand the theoretical reasoning behind it, but realtime scheduling is potentially dangerous, so I have some questions:
Hi @vmatare, thanks for considering the PR.
yes. I made some programming mistakes (with threads and loops) resulting in running hot all CPU cores very fast, with thinkfan running and fan not rotating. This resulted in a whole system freeze (two times), fan was not starting. No hardware broke. My guess was, that it froze because of bad cooling. I then experimented with scheduler priorities. I came up with this solution about 6 months ago and had no issues since then. All this on a 10 year old thinkpad (intel core-i).
Thats correct. I choosed a low priority of 20 because of that. 99 is highest priority for fifo
. Scheduling is done preemptive, so the lower priority thread will be stalled. An additional measure would be to use RoundRobin (RR
) policy, which gives every thread a limited time period for running, before it is rescheduled. - - - - Even tough, I did not test it, in such a situation it should still be possible to kill thinkfan.
I would argument, that it is more important the fan runs (in order to prevent hardware overheating, even if the system freezes) than preventing near-lock-ups because of an unlikely bad-thinkfan-loop on production systems.
Based on this infos: https://man7.org/linux/man-pages/man7/sched.7.html
In case you reject this PR, maybe it is something for the documentation.
It is possible, that the system admin defines a systemd service override, where this realtime scheduling gets enabled.
Run systemd service with realtime priority, to ensure that thinkfan's execution is not delayed in case of sudden rise of CPU load. Deactivated fans on heavy CPU load could otherwise lead to a system freeze.