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:	Wed, 14 Apr 2010 10:25:00 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Raistlin <raistlin@...ux.it>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Chris Friesen <cfriesen@...tel.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Darren Hart <darren@...art.com>,
	Henrik Austad <henrik@...tad.us>,
	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 <t.cucinotta@...up.it>,
	Juri Lelli <juri.lelli@...il.com>,
	Nicola Manica <nicola.manica@...il.com>,
	Luca Abeni <luca.abeni@...tn.it>
Subject: Re: [RFC][PATCH 09/11] sched: first draft of deadline inheritance.

On Sun, 2010-02-28 at 20:26 +0100, Raistlin wrote:
> Therefore, as of now, this patch:
>  - implements priority inheritance for -deadline tasks, according to
>    what described above;
>  - to make this possible without rewriting outstanding chunks of
>    code of both -deadline scheduling and existing PI, the task's
>    relative deadline is stored in the prio field of the task_struct.
>    This is done in such a way that:
>     * prio is always < 0 for -deadline tasks,
>     * p1->prio < p2->prio still means p1 has higher priority than
>       p2, i.e., in our case, p1 has smaller relative deadline.
>  - the point above means that, since prio is of int type, a relative
>    deadline has to be smaller than INT_MAX. This is about 2sec,
>    which is a something (we think! :-)) we can afford, at least
>    for now.

Right, except that this makes the plist stuff O(INT_MAX) [ or rather
O(nr_dl_tasks) ].

But I guess it serves for testing.

I think it would be relatively straight forward to modify the existing
PI chain code to work using an RB-tree instead of the plist stuff.

An RB-tree would also make the whole ->prio mess much easier to solve,
we could simply make a more complex comparison function, like:

int rt_mutex_prio_less(struct task_struct *left, struct task_struct *right)
{
	if (left->prio < right->prio)
		return 1;

	if (left->prio == right->prio && left->prio == -1) {
		if (left->deadline < right->deadline)
			return 1;
	}

	return 0;
}

Which uses the static prio -1 to represent all deadline tasks.

>  - disables bandwidth throttling for tasks while they are deadline
>    boosted. It also tries to make them pay back for runtime overrun
>    and deadline misses in this phase, but it's only "local", in the
>    sense that instances farther than the one right next to the
>    overrun are not going to be direcly affected.
> 
Yeah, good enough to start with ;-)

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ