| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20140513175210.49eed2e34ac06a3c109ce963@gmail.com>
Date: Tue, 13 May 2014 17:52:10 +0200
From: Juri Lelli <juri.lelli@...il.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Dario Faggioli <raistlin@...ux.it>,
lkml <linux-kernel@...r.kernel.org>,
"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [SCHED_DEADLINE man pages 2/2] sched(7) SCHED_DEADLINE
Hello,
On Tue, 13 May 2014 17:00:57 +0200
"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> wrote:
> Hello Peter et al.
>
> Here is the section of the sched(7) page that describes SCHED_DEADLINE,
> as rendered text, with the (entire) raw page source attached. Please
> carefully review.
>
> Cheers,
>
> Michael
>
> SCHED_DEADLINE: Sporadic task model deadline scheduling
> Since version 3.14, Linux provides a deadline scheduling pol‐
> icy (SCHED_DEADLINE). This policy is currently implemented
> using GEDF (Global Earliest Deadline First) in conjunction
> with CBS (Constant Bandwidth Server). To set and fetch this
> policy and associated attributes, one must use the Linux-spe‐
> cific sched_setattr(2) and sched_getattr(2) system calls.
>
> A sporadic task is one that has a sequence of jobs, where
> each job is activated at most once per period. Each job also
> has a relative deadline, before which it should finish execu‐
> tion, and a computation time, which is the CPU time necessary
> for executing the job. The moment when a task wakes up
> because a new job has to be executed is called the arrival
> time (also referred to as the request time or release time).
> The start time is the time at which a task starts its execu‐
> tion. The absolute deadline is thus obtained by adding the
> relative deadline to the arrival time.
>
> The following diagram clarifies these terms:
>
> arrival/wakeup absolute deadline
> | start time |
> | | |
> v v v
> -----x--------xooooooooooooooooo-------x--------x---
> |<- comp. time ->|
> |<------- relative deadline ----->|
> |<-------------- period ------------------>|
>
> When setting a SCHED_DEADLINE policy for a thread using
> sched_setattr(2), one can specify three parameters: Runtime,
> Deadline, and Period. These parameters do not necessarily
> correspond to the aforementioned terms: usual practice is to
> set Runtime to something bigger than the average computation
> time (or worst-case execution time for hard real-time tasks),
> Deadline to the relative deadline, and Period to the period
> of the task. Thus, for SCHED_DEADLINE scheduling, we have:
>
> arrival/wakeup absolute deadline
> | start time |
> | | |
> v v v
> -----x--------xooooooooooooooooo-------x--------x---
> |<-- Runtime --->|
|<-- Runtime --->|
I originally drew this slightly bigger than comp. time above because we
usually don't want tasks to be throttled in the average case. It's just
a rule of thumb.
> |<----------- Deadline ---------->|
> |<-------------- Period ------------------>|
>
> The three deadline-scheduling parameters correspond to the
> sched_runtime, sched_deadline, and sched_period fields of the
> sched_attr structure; see sched_setattr(2). These fields
> express value in nanoseconds. If sched_period is specified
> as 0, then it is made the same as sched_deadline.
>
> The kernel requires that:
>
> sched_runtime <= sched_deadline <= sched_period
>
> In addition, under the current implementation, all of the
> parameter values must be at least 1024 (i.e., just over one
> microsecond, which is the resolution of the implementation).
And below 2^63, as per the last bug fix we discussed.
> If any of these checks fails, sched_setattr(2) fails with the
> error EINVAL.
>
> The CBS guarantees non-interference between tasks, by throt‐
> tling threads that attempt to over-run their specified Run‐
> time.
>
> To ensure deadline scheduling guarantees, the kernel must
> prevent situations where the set of SCHED_DEADLINE threads is
> not feasible (schedulable) within the given constraints. The
> kernel thus performs an admittance test when setting or
> changing SCHED_DEADLINE policy and attributes. This admis‐
> sion test calculates whether the change is feasible; if it is
> not sched_setattr(2) fails with the error EBUSY.
>
> For example, it is required (but not necessarily sufficient)
> for the total utilization to be less than or equal to the
> total number of CPUs available, where, since each thread can
> maximally run for Runtime per Period, that thread's utiliza‐
> tion is its Runtime divided by its Period.
>
> In order to fulfil the guarantees that are made when a thread
> is admitted to the SCHED_DEADLINE policy, SCHED_DEADLINE
> threads are the highest priority (user controllable) threads
> in the system; if any SCHED_DEADLINE thread is runnable, it
> will preempt any thread scheduled under one of the other
> policies.
>
> A call to fork(2) by a thread scheduled under the SCHED_DEAD‐
> LINE policy will fail with the error EAGAIN, unless the
> thread has its reset-on-fork flag set (see below).
>
> A SCHED_DEADLINE thread that calls sched_yield(2) will yield
> the current job and wait for a new period to begin.
>
Thanks,
- Juri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists