linux-kernel - Re: periods and deadlines in 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: <AANLkTilufL0jgoqQLKjxbu0egN2l6lCkF9JPCxBfV3Gz@mail.gmail.com>
Date:	Sat, 10 Jul 2010 19:19:10 +0200
From:	Harald Gustafsson <hgu1972@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Raistlin <raistlin@...ux.it>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Song Yuan <song.yuan@...csson.com>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nicola Manica <nicola.manica@...i.unitn.it>,
	Luca Abeni <lucabe72@...il.it>,
	Claudio Scordino <claudio@...dence.eu.com>,
	Harald Gustafsson <harald.gustafsson@...csson.com>,
	Bjoern Brandenburg <bbb@...il.unc.edu>, bastoni@...unc.edu,
	Giuseppe Lipari <lipari@...is.sssup.it>
Subject: Re: periods and deadlines in SCHED_DEADLINE

2010/7/9 Peter Zijlstra <peterz@...radead.org>:
> One thing we could do, although this would make the proposed scheduler a
> wee bit more complex, is split between hard and soft realtime. Only
> accept P==rel_D for hard, and schedule the soft tasks in the hard slack
> or something like that.
>
> That way we can later extend the hard admission tests to accept more.

Sorry for jumping in a bit late. I'm not that happy with this
suggestion if I understand you correctly. The main reason for having
deadlines shorter than the periods is for tasks that need a short
response time and likely are most important for the system to be
scheduled as fast as possible. Hence if they get scheduled after the
tasks with deadline=period then that defeat the purpose with having a
short deadline. Quite often these tasks are short and hence only need
a low bandwidth, i.e. long period between activations relative to
deadline and runtime.

But also other use cases exist with longer running tasks (e.g. around
5-10 ms) per period (e.g. around 20 ms). You might have several of
such tasks running, but as a system designer you know that their
activation phase will allow them to be scheduled interleaved. This can
be for example you know that the interrupt pattern waking the tasks
are interleaved. The admission test would be even more complex if we
also need to take into account the phases of task periods. Hence I
think some of these things need to be left for the system designer
without being hindered by an admission into the highest hard deadline
scheduling policy. As you might have understood I'm mostly talking
about embedded system, which have some tasks that are central parts of
the running system but which also might in parallel run more generic
software.

Did I get your proposal correct? Do you agree that tasks that need to
set a deadline < period usually do that since they need to be
scheduled in quickly?
--
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/