forge/linux-pinenote
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
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
1 changed files with 23 additions and 24 deletions
Download patch file Download diff file Expand all files Collapse all files

47
Documentation/scheduler/sched-deadline.txt
View file

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