systemd/test/units/sched_rr_ok.service

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

[Service]
ExecStart=true
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 19:07:22 +03: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 21:48:11 +04:00			`[Unit]`
			`Description=Default prio for RR`

			`[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 17:24:52 +03: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 21:48:11 +04:00			`CPUSchedulingPolicy=rr`