- First patch fixes sched-rt sysctl files to disallow writing invalid
values
- Second patch is new in v2 and clarifies and fixes the documentation
for these files and is actually independent of the first patch
Cyril Hrubis (2):
sched/rt: Disallow writing invalid values to sched_rt_period_us
docs: scheduler-rt: Clarify & fix sched_rt_* sysctl docs
Documentation/scheduler/sched-rt-group.rst | 14 ++++++++------
kernel/sched/rt.c | 9 +++++----
2 files changed, 13 insertions(+), 10 deletions(-)
--
2.41.0
- Describe explicitly that sched_rt_runtime_us is allocated from
sched_rt_period_us and hence always less or equal to that value.
- The limit for sched_rt_runtime_us is not INT_MAX - 1 but rather it's
limited by the value of sched_rt_period_us. If sched_rt_period_us is
INT_MAX then sched_rt_runtime_us can be set to INT_MAX as well.
Signed-off-by: Cyril Hrubis <[email protected]>
---
Documentation/scheduler/sched-rt-group.rst | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/scheduler/sched-rt-group.rst b/Documentation/scheduler/sched-rt-group.rst
index 655a096ec8fb..033661a5838f 100644
--- a/Documentation/scheduler/sched-rt-group.rst
+++ b/Documentation/scheduler/sched-rt-group.rst
@@ -87,18 +87,20 @@ lack an EDF scheduler to make non-uniform periods usable.
The system wide settings are configured under the /proc virtual file system:
/proc/sys/kernel/sched_rt_period_us:
- The scheduling period that is equivalent to 100% CPU bandwidth
+ The scheduling period that is equivalent to 100% CPU bandwidth.
/proc/sys/kernel/sched_rt_runtime_us:
- A global limit on how much time realtime scheduling may use. Even without
- CONFIG_RT_GROUP_SCHED enabled, this will limit time reserved to realtime
- processes. With CONFIG_RT_GROUP_SCHED it signifies the total bandwidth
- available to all realtime groups.
+ A global limit on how much time realtime scheduling may use. This is always
+ less or equal than the period_us as it denotes the time allocated from the
+ period_us for the realtime tasks. Even without CONFIG_RT_GROUP_SCHED enabled,
+ this will limit time reserved to realtime processes. With
+ CONFIG_RT_GROUP_SCHED it signifies the total bandwidth available to all
+ realtime groups.
* Time is specified in us because the interface is s32. This gives an
operating range from 1us to about 35 minutes.
* sched_rt_period_us takes values from 1 to INT_MAX.
- * sched_rt_runtime_us takes values from -1 to (INT_MAX - 1).
+ * sched_rt_runtime_us takes values from -1 to sched_rt_period_us.
* A run time of -1 specifies runtime == period, ie. no limit.
--
2.41.0
* Cyril Hrubis <[email protected]> wrote:
> - Describe explicitly that sched_rt_runtime_us is allocated from
> sched_rt_period_us and hence always less or equal to that value.
Just some spelling nits:
> - The limit for sched_rt_runtime_us is not INT_MAX - 1 but rather it's
> limited by the value of sched_rt_period_us. If sched_rt_period_us is
> INT_MAX then sched_rt_runtime_us can be set to INT_MAX as well.
s/is not INT_MAX - 1 but rather it's
/is not INT_MAX-1, but rather it's
> /proc/sys/kernel/sched_rt_runtime_us:
> - A global limit on how much time realtime scheduling may use. Even without
> - CONFIG_RT_GROUP_SCHED enabled, this will limit time reserved to realtime
> - processes. With CONFIG_RT_GROUP_SCHED it signifies the total bandwidth
> - available to all realtime groups.
> + A global limit on how much time realtime scheduling may use. This is always
s/realtime
/real-time
> + less or equal than the period_us as it denotes the time allocated from the
s/than the period_us as it denotes
/than the period_us, as it denotes
> + period_us for the realtime tasks. Even without CONFIG_RT_GROUP_SCHED enabled,
> + this will limit time reserved to realtime processes. With
s/realtime
/real-time
> + CONFIG_RT_GROUP_SCHED it signifies the total bandwidth available to all
s/CONFIG_RT_GROUP_SCHED
/CONFIG_RT_GROUP_SCHED=y
> + realtime groups.
s/realtime
/real-time
Thanks,
Ingo