linux-kernel - Re: [RFC][PATCH 02/22] sched: add extended scheduling interface

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:	Thu, 11 Nov 2010 00:33:17 +0100
From:	Tommaso Cucinotta <tommaso.cucinotta@...up.it>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Raistlin <raistlin@...ux.it>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Chris Friesen <cfriesen@...tel.com>, oleg@...hat.com,
	Frederic Weisbecker <fweisbec@...il.com>,
	Darren Hart <darren@...art.com>,
	Johan Eker <johan.eker@...csson.com>,
	"p.faure" <p.faure@...tech.ch>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Claudio Scordino <claudio@...dence.eu.com>,
	michael trimarchi <trimarchi@...is.sssup.it>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Tommaso Cucinotta <cucinotta@...up.it>,
	Juri Lelli <juri.lelli@...il.com>,
	Nicola Manica <nicola.manica@...i.unitn.it>,
	Luca Abeni <luca.abeni@...tn.it>,
	Dhaval Giani <dhaval@...is.sssup.it>,
	Harald Gustafsson <hgu1972@...il.com>,
	paulmck <paulmck@...ux.vnet.ibm.com>
Subject: Re: [RFC][PATCH 02/22] sched: add extended scheduling interface

Il 10/11/2010 20:26, Peter Zijlstra ha scritto:
>> I would suggest we add at least one more field so we can implement the
>> stochastic model from UNC, sched_runtime_dev or sched_runtime_var or
>> somesuch.
> Oh, and their model has something akin to: sched_runtime_max, these
> Gaussian bell curves go to inf. which is kinda bad for trying to compute
> bounds.
If I understand well the paper you're referring to, the actual admission 
test would require also to specify a maximum acceptable expected 
tardiness, and/or proper quantiles of the tardiness distribution, and 
also it would require to solve a linear programming optimization problem 
in order to check those bounds. You don't want this stuff to go into the 
kernel, do you ?

There are plenty of complex schedulability tests for complex (and also 
distributed) RT applications modeled in a more or less complex way, 
scheduled under a variety of scheduling policies, with models including 
maximum and stochastic blocking times, task dependencies, offsets, and I 
don't know whatever else. These tests may be part of a user-space 
component. I would recommend to keep at the kernel level only a bare 
minimal set of functionality.

Deadlines different from periods are already a first complexity that I'm 
not sure we want to have in the interface. The easiest thing you can do 
there is to consider simply the minimum among the relative deadline and 
the period, but that would be equivalent to having only one parameter. 
More importantly, realizing complex admission control tests raises the 
issue of how to represent the "availability of RT CPU power" (as needed 
by "higher-level" logic/middleware). As far as we keep simple 
utilization-based admission tests (which might optionally be disabled), 
we still have some chance of representing such quantity.

Apologies for my 2 poor cents. I hope to see here a discussion (and I'll 
try to shut-up as much as possible :-) ).

     T.

-- 
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso

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