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:

RHEL7.5 RT kernel has a downstream-only feature called RT_RUNTIME_GREED. This feature allows a SCHED_OTHER task to preempt a fifo:1 task for a limited amount of time. We've decided to enable it in the host and guest KVM-RT profiles in order to have a workaround for issue like bug 1448770, where starvation of SCHED_OTHER kernel threads can lead to system lockup.

NOTE: In its current version, RT_RUNTIME_GREED allows a SCHED_OTHER task to run for a maximum of 1ms. This is too much time for real-time. The RT team is trying to find a way to have a maximum of 10us preemption duration.

Version-Release number of selected component (if applicable): tuned-2.9.0-0.1.rc1.el7.noarch

Marcelo has a better proposal for this issue, which is to change DPDK to allow yielding the CPU for short periods (say 10us). He's going to post a patch upstream.

I'll keep this open for now as Marcelo's idea depends on upstream acceptance.

We have decided we won't be enabling this for KVM-RT. There are two reasons for this decision:

1. This still causes a spike, so even if we enable this we wouldn't be done with our main issue (which is bug 1448770)

2. We've found the series that introduces the bug 1448770 (see bug 1448770 comment 100), so we know how to get it fixed without this anyways