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]
Date:	Mon, 12 Jul 2010 12:21:47 +0200
From:	Harald Gustafsson <hgu1972@...il.com>
To:	Bjoern Brandenburg <bbb@...il.unc.edu>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	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>,
	bastoni@...unc.edu, Giuseppe Lipari <lipari@...is.sssup.it>
Subject: Re: periods and deadlines in SCHED_DEADLINE

2010/7/11 Bjoern Brandenburg <bbb@...il.unc.edu>:
> Trying to infer whether a task is "hard" or "soft" from task parameters is not a good idea, IMO. It's much better to make this an explicit part of the task model that is configured via sched_setparam. By default, tasks should be marked "soft" (this leaves more wiggle room to the kernel); users who care can change the flag to "hard".

Yes, this was along the lines of my suggestions also.

> Taking a step back, I think the problem here is that we are trying to shove too many concepts and properties into a single scheduler. Hard (no tardiness) is different from soft (bounded tardiness) is different from global is different from partitioned.
>
> From my point of view, it makes no sense to support hard deadlines under G-EDF (this is backed up by our schedulability studies [1]). Hard deadlines are best served by a P-EDF implementation (that only migrates on task creation/admission).
>
> Also, it makes little sense to worry about supporting both hard and soft in a P-EDF implementation. Just schedule everything by its deadline and both hard and soft tasks will be fine (if the admissions test was passed).
>
> In my opinion, it is much more useful to have a two-level scheduling framework: a truly partitioned EDF implementation at the top level to support "hard" tasks, and a truly global EDF implementation at the second level for "soft" tasks, with the property that the second level implementation is only invoked if the first level is idle. This nicely matches Linux's scheduling class hierarchy.

Would this prevent soft RT tasks to be pinned to a specific CPU, i.e.
have an affinity set of one CPU? I'm asking since we would like to use
soft deadline RT (bounded tardiness, e.g. with relative deadlines
short than periods), but with threads set to run on a specific CPU.
This is due to that we do an analysis on data dependencies etc in user
space applications (or offline) and distribute jobs among threads on
each CPU. At the same time we would like the isolation between
parallel running such applications and other CPU activities.

I'm not saying that all soft RT needs to be pinned or that some such
tasks can't be made to meet hard admission control but we would need
the possibility. If I would need to priorities between soft deadline
RT and CPU affinity, soft deadline RT would win, since it is still
quite likely that the tasks get scheduled on individual cores when
needed.

When you say truly global EDF implementation does that mean the
scheduler only considers relative deadline and may "migrate" a thread
among all the CPUs at each scheduling instance, disregarding cache
effects, power management (e.g. waking an idle core), etc? Or can
these things be factored into the relative deadlines (maybe they
already are by the user)?

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