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]

Date:	Sun, 11 Jul 2010 07:41:31 +0200
From:	Harald Gustafsson <hgu1972@...il.com>
To:	Raistlin <raistlin@...ux.it>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	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/10 Raistlin <raistlin@...ux.it>:
> Indeed. I think things might be done step by step, relaxing the
> constraints as long as we find better solutions.
Yes, I definitely think the step by step approach is best here. So
that eventually its possible to use hard deadline RT also for more
complex task activation patterns.

>> > Embedded people can of course easily hack in whatever they well fancy,
>> > and adding the 'yes_I_really_want_this_anyway' flag or even taking out
>> > admission control all together is something the GPL allows them to do.
>>
>> Not an option I would like to pursue, it should be possible to get a
>> working solution without this.
>>
> Yeah, I see your point and agree with it. Btw, I think that, even in the
> configuration described by Peter, if you --as an embedded system
> engineer-- have the full control of your device/product, you can avoid
> having any hard-rt task. Then, if you only have soft ones, you'll get
> the benefit of having the possibility of setting D!=P without suffering
> of any interference... Am I right?

Yes, this is exactly what I mean. As long as the interface gives the
user control to be able to demote a task to soft RT even if the
admission control could allow it into the hard RT policy. Then later
when we have managed to include more complex admission controls into
the kernel, the system designer could when his system setup is handled
move over to always use hard RT. This would also mean that people
would start using the DL scheduler and having a motivation of
improving the admission control, because it is preferred to have the
benefit of reliable isolation between tasks.

> I think this could be a viable solution, at least until we have
> something better to relax assumptions on the schedulability test for
> hard tasks, isn't it?
Yes, I agree.

Regards,
  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/