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

 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.

 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.

 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

 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.

 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.

 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: