lkml.org 
[lkml]   [2014]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 3/4] Documentation/scheduler/sched-deadline.txt: improve and clarify AC bits
    Hi,

    On 03/09/14 07:49, Luca Abeni wrote:
    > Hi,
    >
    > On 09/02/2014 11:45 PM, Henrik Austad wrote:
    > [...]
    >>> + On multiprocessor systems with global EDF scheduling (non partitioned
    >>> + systems), a sufficient test for schedulability can not be based on the
    >>> + utilisations (it can be shown that task sets with utilisations slightly
    >>> + larger than 1 can miss deadlines regardless of the number of CPUs M).
    >>> + However, as previously stated, enforcing that the total utilisation is smaller
    >>> + than M is enough to guarantee that non real-time tasks are not starved and
    >>> + that the tardiness of real-time tasks has an upper bound.
    >>
    >> I'd _really_ appreciate a link to a paper where all of this is presented
    >> and proved!
    > Well, my original plan was to add the bibliography in the next round of patches...
    > Is this ok?
    >
    > [...]
    >>> + As already stated in Section 3, a necessary condition to be respected to
    >>> + correctly schedule a set of real-time tasks is that the total utilisation
    >>> + is smaller than M. When talking about -deadline tasks, this requires to
    >>> + impose that the sum of the ratio between runtime and period for all tasks
    >>> + is smaller than M.
    >>
    >> "This requires to impose that .." uhm, what? Drop 'to impose'.
    > Ok. I'll send an updated patch to Juri in few days
    >
    >
    >>> [...] Notice that the ratio runtime/period is equivalent to
    >>> + the utilisation of a "traditional" real-time task, and is also often
    >>> + referred to as "bandwidth".
    >>> + The interface used to control the 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).
    >>> @@ -232,8 +285,16 @@ CONTENTS
    >>> 950000. With rt_period equal to 1000000, by default, it means that -deadline
    >>> tasks can use at most 95%, multiplied by the number of CPUs that compose the
    >>> root_domain, for each root_domain.
    >>> -
    >>> - A -deadline task cannot fork.
    >>> + This means that non -deadline tasks will receive at least 5% of the CPU time,
    >>> + and that -deadline tasks will receive their runtime with a guaranteed
    >>> + worst-case delay respect to the "deadline" parameter. If "deadline" = "period"
    >>> + and the cpuset mechanism is used to implement partitioned scheduling (see
    >>> + Section 5), then this simple setting of the bandwidth management is able to
    >>> + deterministically guarantee that -deadline tasks will receive their runtime
    >>> + in a period.
    >>
    >> The whole 950000 / 1000000, is at least 50 *consecutive* ms given to non
    >> rt/dl tasks every second, or is this more finegrained now?
    >>
    >> If the 50ms can be given in a single go, then I don't think you can
    >> guarantee that deadline-tasks will receive their runtime in a period - a
    >> period can be <50ms, no?
    > Uhmm... Maybe there is something I am missing in how the SCHED_DEADLINE admission
    > control is implemented, but I do not know about any "50 consecutive ms to non dl
    > tasks" rule. I agree that if there is such a rule then deadline tasks are screwed.
    > Juri?
    >
    >

    In SCHED_DEADLINE we use those values only at admission control time (when
    the user calls sched_setattr()). Then, at runtime, we use tasks' parameters
    to perform scheduling. So there is no consecutive 50ms time for !SCHED_DEADLINE
    tasks.

    We could probably clarify this aspect in the previous patch with something
    like this:

    [snip]
    + 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. In other words, this means that interface parameters are
    + only used at admission control time (i.e., when the user calls
    + sched_setattr()). Scheduling is then performed considering actual tasks'
    + parameters, so that CPU bandwidth is allocated to SCHED_DEADLINE tasks
    + respecting their needs in terms of granularity. Therefore, using this simple
    <---
    + interface we can put a cap on total utilization of -deadline tasks (i.e.,
    + \Sum (runtime_i / period_i) < some_desired_value).
    [snip]

    What you think?

    Thanks,

    - Juri

    >>> + Finally, notice that in order not to jeopardize this admission control a
    >>> + -deadline task cannot fork.
    >>
    >> s/this/the
    >> (there aren't any other admission controls in the kernel)
    > Ok; this will go in my updated patch
    >
    >
    >
    > Thanks,
    > Luca
    >



    \
     
     \ /
      Last update: 2014-09-03 12:01    [W:7.512 / U:0.492 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site