Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
RHEL kernel has CONFIG_RT_GROUP_SCHED option enabled making impossible for userspace application to gain RT priority (by calling sched_setscheduler (0, SCHED_RR, ... ) until process is moved to root cgroup. Sadly this is causing problem described in bug 1962768.
Solution recommended by systemd developers is to assign RT budget into cgroup, but sadly this looks impossible with cgroup v2 (https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#cpu)
All and all, because it is not possible to assign RT budget I think it may be solution to simply disable CONFIG_RT_GROUP_SCHED (as in Fedora for example). Better solution would be to allow configuration of RT budget.
Version-Release number of selected component (if applicable):
5.13.0-0.rc7.51.el9
How reproducible:
100%
Steps to Reproduce:
1. Ensure /sys/fs/cgroup/cgroup.subtree_control contains "cpu" - for example by having service with CPUQuota option
2. Run application which asks for rt priority
Actual results:
Application cannot gain rt priority, or when moves itself to root cgroup logging doesn't get correct tag (as described in bug 1962768).
Expected results:
Option 1: CONFIG_RT_GROUP_SCHED disabled so application can gain rt priotity
Option 2: It is possible to configure RT budget with cgroup v2
(In reply to Jan Friesse from comment #0)
> Description of problem:
> RHEL kernel has CONFIG_RT_GROUP_SCHED option enabled making impossible for
> userspace application to gain RT priority (by calling sched_setscheduler (0,
> SCHED_RR, ... ) until process is moved to root cgroup. Sadly this is causing
> problem described in bug 1962768.
Yes, this is a known issue and we are considering disabling CONFIG_RT_GROUP_SCHED for RHEL9, i.e. option 1.
-Longman
(In reply to Waiman Long from comment #4)
> (In reply to Phil Auld from comment #3)
> > Fwiw, I've put in an MR against ark to disable this.
> >
> > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1177
> >
> > It could use more acks :)
>
> I am aware you have an outstanding kernel-ark MR. I have just ack'ed it.
Maybe you can update the MR description to add this BZ.
-Longman
(In reply to Phil Auld from comment #6)
> ARK changes don't usually get RHEL BZs associated with them do they? I can
> certainly add it to the MR comment though if you want.
I am OK if you don't want to add it. It is up to you.
Being in charge of a userspace-daemon (SBD = Storage Based Death) that needs RT-scheduling I ran into similar issues with CONFIG_RT_GROUP_SCHED - already some time back when I tried to extrapolate how RHEL9 kernel might look like from f31 kernel.
Adding my comment here as I had tried to identify the situation where extra actions had to be taken because of CONFIG_RT_GROUP_SCHED being set.
And the only way I found was checking for "rt_rq[...]:/" in /proc/sched_debug (given it is a kernel with /proc/config disabled).
Grepping in debug-statistics is of course surper-ugly.
Reference to my code playing with the issue: https://github.com/wenningerk/sbd/commit/763e3a0c2ca87c76dddf598ba3355811300ffa59
Finally it turned of course out that there were no real options to properly deal with the issue (as mentioned above already).
But still proper detection and reporting of a doomed kernel-config would be desirable (even if it might not trigger in final RHEL9 once CONFIG_RT_GROUP_SCHED is disabled).