linux-kernel - Re: [PATCH] sched/deadline: Add sched

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52DD2711.9080504@unitn.it>
Date:	Mon, 20 Jan 2014 14:39:29 +0100
From:	Luca Abeni <luca.abeni@...tn.it>
To:	Henrik Austad <henrik@...tad.us>, Juri Lelli <juri.lelli@...il.com>
CC:	peterz@...radead.org, tglx@...utronix.de, mingo@...hat.com,
	rostedt@...dmis.org, oleg@...hat.com, fweisbec@...il.com,
	darren@...art.com, johan.eker@...csson.com, p.faure@...tech.ch,
	linux-kernel@...r.kernel.org, claudio@...dence.eu.com,
	michael@...rulasolutions.com, fchecconi@...il.com,
	tommaso.cucinotta@...up.it, nicola.manica@...i.unitn.it,
	dhaval.giani@...il.com, hgu1972@...il.com,
	paulmck@...ux.vnet.ibm.com, raistlin@...ux.it,
	insop.song@...il.com, liming.wang@...driver.com, jkacur@...hat.com,
	harald.gustafsson@...csson.com, vincent.guittot@...aro.org,
	bruce.ashfield@...driver.com, rob@...dley.net
Subject: Re: [PATCH] sched/deadline: Add sched_dl documentation

Hi all,

On 01/20/2014 02:16 PM, Henrik Austad wrote:
[...]
>>>> + The typical -deadline task is composed of a computation phase (instance)
>>>> + which is activated on a periodic or sporadic fashion. The expected (maximum)
>>>> + duration of such computation is called the task's runtime; the time interval
>>>> + by which each instance needs to be completed is called the task's relative
>>>> + deadline. The task's absolute deadline is dynamically calculated as the
>>>> + time instant a task (or, more properly) activates plus the relative
>>>> + deadline.
>>>
>>> activates - released?
>>>
>>
>> I'd keep (modifying a bit):
>>
>> "time instant a task activates plus the relative deadline."
>>
>> This is probably the nearest thing to what is implemented that we can say
>> (without entering into the theory too much), a task that "activates" can mean
>> that it is first released, enqueued, woken-up, etc.
>
> So, if we look at release (yes, I'm avoiding activates for a little while)
> as the time at the *beginning* of a new period, then, and only then should
> the *absolute* deadline be computed.
>
> If you den move on to use 'activate' as a term for when a task becomes
> eligble to run, then 'release' becomes a subset of 'activate', and you
> should only compute the absolute deadline at that time. Did that make
> sense?
I think things are a little bit complex here, because there are 2 different
"deadlines" we can think about:
- the "jobs deadlines" (the absolute job deadline can be computed at job
   arrival, as the arrival time + the relative deadline). These are generally
   used for performance metrics, to see if a job is respecting its timing
   constraints or not
- the "scheduling deadlines", which are the ones used by the scheduler to
   schedule the tasks. These are computed at tasks' wake-up time - notice that
   for self-suspending jobs there can be wake-up times that are not job arrival
   times. And are assigned according to the rules described in the CBS paper.
I think this can easily become very confusing, so I currently have no concrete
proposals for improving the documentation... But I wanted to point out that
things here are more complex than in the "traditional" real-time task model.

Maybe a solution could be to simply describe scheduling deadlines (which are
what sched_deadline uses) without going into the details of jobs' deadlines.
So, the document could avoid talking about instances (or jobs), and can say
that a task is guaranteed to receive "runtime" time units every "period" time
units (and these "runtime" time units are available within "deadline" time
units from the beginning of the period). Every time the task wakes up, the
scheduler computes a scheduling deadline consistent with this constraint,
and tasks are scheduled using EDF on these scheduling deadlines.
Every time "runtime" time units are consumed in a period, the scheduling
deadline is postponed by a period.

This is of course an approximative description, but I think it can give an
intuitive idea of how the scheduler works, and about the meaning of the three
scheduling parameters.



				Luca
--
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/