Bug 1491722

Summary: Add the RT_RUNTIME_GREED sched feature to the RT Tuning Doc
Product: Red Hat Enterprise Linux 7 Reporter: Beth Uptagrafft <bhu>
Component: doc-Realtime_Tuning_GuideAssignee: Jana Heves <jsvarova>
Status: CLOSED CURRENTRELEASE QA Contact: Jiri Kastner <jkastner>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.5CC: bhu, daolivei, lgoncalv, rhel-docs, williams
Target Milestone: rcKeywords: Documentation, FutureFeature
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-12 14:34:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1470091    

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