sched test failures in RHEL8 - no rt_runtime set

[mpw5421]

I opened a bug against RedHat for LTP failures on RHEL8.9 for these tests which I ran on LPAR & z/VM on s390x (although the failures are apparently not s390x specific):

sched_rr_get_interval01
sched_rr_get_interval02
sched_rr_get_interval03
sched_setparam02
sched_setparam03
sched_getscheduler01
time-schedule01
trace_sched01

Example output from one of the failing tests:

./time-schedule

root@a35lp04:/opt/ltp/testcases/bin# ./time-schedule
Error changing to RT class      Operation not permitted

I received this response from RedHat:

This is due to not having any rt_runtime to work with. It looks like systemd is defaulting to creating user.slice cgroups with cpu accounting enabled despite the fact that that was supposed to be off by default. See https://access.redhat.com/articles/3696121. I was unable to convince systemd to respect the DefaultCPUAccounting=no directive. I've asked someone from systemd about it. This is not a kernel bug though.

If you do something like

echo 50000 > /sys/fs/cgroup/cpu/user.slice/cpu.rt_runtime_us

the run the test it works as expected. You can also verify with e.g. 'chrt -f 50 ls'

This applies to all of these failures similar failures. I'm not sure when started. Also, it's not s390 specific.

This is due to insights-client.service and insights-client-boot.service which have CPUQuota= directives. I guess that makes this expected. It seems that by default rhel8 will have CPU accounting enabled. So I think this is adequately, if somewhat misleadingly, documented in the KB article above.

Since RedHat considered it expected behavior which was resolved with their provided workaround the bug was set to "CLOSED DOCUMENTED" and I was instructed by my team to see if the LTP project would consider making an update to resolve the issue. All of the tests I listed require the rt_runtime value to be defined so I was wondering if it would be appropriate to add that definition as a preparatory step to the tests.

If that's not an appropriate course of action I understand. We can update our wrapper around the LTP testcase to resolve the issue. Thanks in advance.