systemd/test/units/sched_rr_change.service

# SPDX-License-Identifier: LGPL-2.1-or-later
[Unit]
Description=Change prio

[Service]
ExecStart=true
CPUSchedulingPriority=1
CPUSchedulingPriority=2
CPUSchedulingPriority=99
CPUSchedulingPolicy=rr
tests: add spdx license header to test unit/link/network/conf files Those are all consumed by our parser, so they all support comments. I was considering whether they should have a license header at all, but in the end I decided to add it because those files are often created by copying parts of real unit files. And if the real ones have a license, then those might as well. It's easier to add it than to make an exception. 2021-10-17 16:07:22 +00:00			`# SPDX-License-Identifier: LGPL-2.1-or-later`
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100 2012-11-01 17:48:11 +00:00			`[Unit]`
			`Description=Change prio`

			`[Service]`
tests: use relative paths in ExecStart= and friends We want to retain some of the full paths in order to test more code paths. But the default should be to use the command name only. This makes the tests less visually cluttered. 2024-01-04 14:24:52 +00:00			`ExecStart=true`
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100 2012-11-01 17:48:11 +00:00			`CPUSchedulingPriority=1`
			`CPUSchedulingPriority=2`
			`CPUSchedulingPriority=99`
service: do fine-grained validation of CPUSchedulingPriority= at execution time The precise bounds of the scheduling priority depend on the scheduling policy, so depending on the order in which the two settings are specified the validation might pass or fail. When checking the setting only validate the outer range (valid values in general are 0 to 99), and let the execution fail later if the priority does not match the specified policy (1 to 99 for RR/FIFO, 0 for the rest). Fixes https://github.com/systemd/systemd/issues/20320 2022-10-19 22:52:58 +00:00			`CPUSchedulingPolicy=rr`