linux-kernel - Re: [PATCH v3 3/4] Documentation/scheduler/sched-deadline.txt: improve and clarify AC bits

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: <5406BA02.20806@unitn.it>
Date:	Wed, 03 Sep 2014 08:49:38 +0200
From:	Luca Abeni <luca.abeni@...tn.it>
To:	Henrik Austad <henrik@...tad.us>, Juri Lelli <juri.lelli@....com>
CC:	peterz@...radead.org, rdunlap@...radead.org, mingo@...hat.com,
	raistlin@...ux.it, juri.lelli@...il.com, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/4] Documentation/scheduler/sched-deadline.txt: improve
 and clarify AC bits

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?


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