Documentation/scheduler/sched-deadline.txt: Rewrite section 4 intro

Section 4 intro was still describing the old interface. Rewrite
it.

Signed-off-by: Juri Lelli <juri.lelli@arm.com>
Signed-off-by: Luca Abeni <luca.abeni@unitn.it>
Reviewed-by: Henrik Austad <henrik@austad.us>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Dario Faggioli <raistlin@linux.it>
Cc: Juri Lelli <juri.lelli@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1410256636-26171-3-git-send-email-juri.lelli@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Juri Lelli 2014-09-09 10:57:13 +01:00 committed by Ingo Molnar
parent ad67dc316f
commit 0d9ba8b03c

View File

@ -165,39 +165,38 @@ CONTENTS
In order for the -deadline scheduling to be effective and useful, it is
important to have some method to keep the allocation of the available CPU
bandwidth to the tasks under control.
This is usually called "admission control" and if it is not performed at all,
no guarantee can be given on the actual scheduling of the -deadline tasks.
bandwidth to the tasks under control. This is usually called "admission
control" and if it is not performed at all, no guarantee can be given on
the actual scheduling of the -deadline tasks.
Since when RT-throttling has been introduced each task group has a bandwidth
associated, calculated as a certain amount of runtime over a period.
Moreover, to make it possible to manipulate such bandwidth, readable/writable
controls have been added to both procfs (for system wide settings) and cgroupfs
(for per-group settings).
Therefore, the same interface is being used for controlling the bandwidth
distrubution to -deadline tasks.
The interface used to control the fraction of CPU bandwidth that can be
allocated to -deadline tasks is similar to the one already used for -rt
tasks with real-time group scheduling (a.k.a. RT-throttling - see
Documentation/scheduler/sched-rt-group.txt), and is based on readable/
writable control files located in procfs (for system wide settings).
Notice that per-group settings (controlled through cgroupfs) are still not
defined for -deadline tasks, because more discussion is needed in order to
figure out how we want to manage SCHED_DEADLINE bandwidth at the task group
level.
However, more discussion is needed in order to figure out how we want to manage
SCHED_DEADLINE bandwidth at the task group level. Therefore, SCHED_DEADLINE
uses (for now) a less sophisticated, but actually very sensible, mechanism to
ensure that a certain utilization cap is not overcome per each root_domain.
Another main difference between deadline bandwidth management and RT-throttling
A main difference between deadline bandwidth management and RT-throttling
is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
and thus we don't need an higher level throttling mechanism to enforce the
desired bandwidth.
and thus we don't need a higher level throttling mechanism to enforce the
desired bandwidth. Therefore, using this simple interface we can put a cap
on total utilization of -deadline tasks (i.e., \Sum (runtime_i / period_i) <
global_dl_utilization_cap).
4.1 System wide settings
------------------------
The system wide settings are configured under the /proc virtual file system.
For now the -rt knobs are used for dl admission control and the -deadline
runtime is accounted against the -rt runtime. We realise that this isn't
entirely desirable; however, it is better to have a small interface for now,
and be able to change it easily later. The ideal situation (see 5.) is to run
-rt tasks from a -deadline server; in which case the -rt bandwidth is a direct
subset of dl_bw.
For now the -rt knobs are used for -deadline admission control and the
-deadline runtime is accounted against the -rt runtime. We realise that this
isn't entirely desirable; however, it is better to have a small interface for
now, and be able to change it easily later. The ideal situation (see 5.) is to
run -rt tasks from a -deadline server; in which case the -rt bandwidth is a
direct subset of dl_bw.
This means that, for a root_domain comprising M CPUs, -deadline tasks
can be created while the sum of their bandwidths stays below: