Message-ID: <552655E8.4020606@unitn.it>
Date: Thu, 09 Apr 2015 12:35:20 +0200
From: Luca Abeni <luca.abeni@unitn.it>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Henrik Austad <henrik@austad.us>
CC: Luca Abeni <lucabe72@gmail.com>, peterz@infradead.org,
        juri.lelli@gmail.com, raistlin@linux.it, mingo@kernel.org,
        linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [RFC 3/4] Documentation/scheduler/sched-deadline.txt: Some notes
 on EDF schedulability
References: <1428494380-1917-1-git-send-email-luca.abeni@unitn.it> <1428494380-1917-4-git-send-email-luca.abeni@unitn.it> <20150409090637.GA10954@sisyphus.home.austad.us> <552647AD.3040807@unitn.it> <20150409101058.GC10954@sisyphus.home.austad.us>
In-Reply-To: <20150409101058.GC10954@sisyphus.home.austad.us>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2615
Lines: 50

On 04/09/2015 12:10 PM, Henrik Austad wrote:
[...]
>>> @@ -43,7 +43,13 @@ CONTENTS
>>>    "deadline", to schedule tasks. A SCHED_DEADLINE task should receive
>>>    "runtime" microseconds of execution time every "period" microseconds, and
>>>    these "runtime" microseconds are available within "deadline" microseconds
>>> - from the beginning of the period.  In order to implement this behaviour,
>>> + from the beginning of the period.
>>> +
>>> + We can the describe a task in a concise manner:
>>> +
>>> +      T_i = {period, WCET, deadline}
>>> +
>>> + In order to implement this behaviour,
>> Notice that these "period" and "runtime" are different things respect to the
>> task period and WCET described in Section 3 (the relationship between them is
>> explained at the end of Section 3: "Finally, it is important to understand the
>> relationship...").
>
> Ok. I understood runtime as the dynamic value being managed by the
> scheduler and should never exceed WCET (or being set to WCET upon release
> and task preemption when runtime==0).
Uh... That's yet another thing (called "remaining runtime" in the document).

This is the situation:
1) A task is characterised by 3 parameters: WCET, D, and P. These only depend on the
    application's code (how much time the application takes to do its work, how often
    it activate, and how fast it should finish in order to respect its temporal
    constraints).
    Section 3 tries to introduce and describe these parameters (which come from real-time
    literature).
2) The SCHED_DEADLINE scheduler accepts 3 scheduling parameters (as arguments of the
    sched_setattr() system call): runtime, deadline and period. These are used by the
    scheduler to assign a dynamic priority to the tasks. Described in Section 2.
3) Internally, the scheduler maintains some dynamic values (remaining budget and
    scheduling deadline). The "remaining budget" starts from the "budget" value and
    decreases when a task executes. When it arrives to 0 the task is throttled, etc...

The problem is that the scheduling parameters (runtime deadline and period, item 2
and Section 3) and the task's parameters (WCET D and P, item 1 and Section 2) are
conceptually two different things... And of course the task's temporal constraints
are respected only if the scheduling parameters are set in an appropriate way.


					Luca
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/