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.
Bug 1491722 - Add the RT_RUNTIME_GREED sched feature to the RT Tuning Doc
Summary: Add the RT_RUNTIME_GREED sched feature to the RT Tuning Doc
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: doc-Realtime_Tuning_Guide
Version: 7.5
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jana Heves
QA Contact: Jiri Kastner
URL:
Whiteboard:
Depends On:
Blocks: 1470091
TreeView+ depends on / blocked
 
Reported: 2017-09-14 13:40 UTC by Beth Uptagrafft
Modified: 2019-03-06 00:56 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-12 14:34:01 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Beth Uptagrafft 2017-09-14 13:40:11 UTC
We need to explain how the new RT_RUNTIME_GREED sched feature can be used and why it will be helpful. Reference bz#1401061.

Comment 3 Beth Uptagrafft 2017-09-14 14:01:13 UTC
Please let us know what the deadline is to provide the technical information.

Comment 5 Jana Heves 2017-10-17 13:04:33 UTC
RFE: Improve RT throttling mechanism bug is ON_QA [1]. 

Dear Daniel,

do you think you could provide us with more information on improvements to RT throttling mechanism to update the respective chapter in RT Tuning Guide [2]?. 

I'll be grateful for any relevant information you have for us. The goal, however, is to create a USER STORY, that is, a short description of what the user does to achieve a goal. (In our case, I guess, something like:
As the system administrator, I want to allocate CPU bandwith for use by a realtime task so that my realtime task has 95% of CPU time available and thus its performance is most effective.)

Thank you very much in advance.
jana


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1401061 
[2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_for_Real_Time/7/html-single/Tuning_Guide/index.html#Real_Time_Throttling

Comment 6 Daniel Bristot de Oliveira 2017-10-18 14:18:49 UTC
Hi, Jana!

How about this:

------------------------------ %< -------------------------
The rt throttling mechanism prevents the starvation of non-real-time
tasks by CPU intensive real-time tasks. In terms of percentage,
the default behavior allows real-time tasks to run up to 95% of a
given period, leaving the other 5% of the period for non-real-time
tasks,. In the absence of non-rt tasks, the system goes idle for 5%
of the period.

Although this behavior works fine for the purpose of avoiding
bad real-time tasks that can hang the system, some advanced users
want to allow the real-time task to continue running in the absence
of non-real-time tasks starving. In other words, they do not want to
see the system going idle.

This patch implements the RT_RUNTIME_GREED scheduler feature that, when
enabled, this feature checks if non-rt tasks are starving before
throttling the real-time task. If the real-time task becomes throttled,
it will be unthrottled as soon as the system goes idle, or when the
next period starts, whichever comes first.

This feature is enabled with the following command:
  # echo RT_RUNTIME_GREED > /sys/kernel/debug/sched_features

The user will also want to disable NO_RT_RUNTIME_SHARE logic,
to keep all CPUs with the same rt_runtime.
  # echo NO_RT_RUNTIME_SHARE > /sys/kernel/debug/sched_features

With these two options set, the user will guarantee some runtime
for non-rt-tasks on all CPUs, while keeping real-time tasks running
as much as possible.

The feature is disabled by default, keeping the current behavior.
------------------------------ >% -------------------------

Looks good?

Thanks!
-- Daniel

Comment 8 Daniel Bristot de Oliveira 2017-11-06 10:04:20 UTC
Hi Jana,

The text looks great! I have just fewer comments:


1) The sub-title should be:
   
     The RT_RUNTIME_GREED feature

As it is a feature, not a scheduler.


2) The indentation of the next paragraph seems not to be correct.

3) Real-time is writing with a "dash" separating the Real from Time (Real-time). That's because the Real is a characteristic of the time - that is how we use in the academic world, e.g., the main book about real-time is named "Hard Real-time Computing Systems."

So, could you please change the "realtime" usage to real-time?

That is all! Thanks! Have a nice week :-).

-- Daniel


Note You need to log in before you can comment on or make changes to this bug.