All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jussi Laako <jussi@sonarnerd.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: James Courtier-Dutton <James@superbug.co.uk>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [RFC][PATCH] Multimedia scheduling class, take 2
Date: Mon, 11 May 2009 11:22:28 +0300	[thread overview]
Message-ID: <4A07E044.8040807@sonarnerd.net> (raw)
In-Reply-To: <1232954745.4863.4.camel@laptop>

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

Hi,

Peter Zijlstra wrote:
> Right, and I think the solution to this problem is twofold, 1)
> application writers should start writing (soft) realtime applications if
> they want (soft) realtime behaviour -- there's just no way around that.

Just to avoid need for reviewing and reworking ~800 klocs of user space
code in just gstreamer, here's a second take on patches. This time
splitting things into smaller pieces. Attached patch exposes 40
priorities ~ nice values as something accessible through
sched_()/pthreads API in order to control priorities of individual
threads. Current Linux implementation of SCHED_OTHER is broken in a way,
that it exposes only one single priority level - 0. Thus no possibility
to properly control priorities of threads through pthread API. This is
patch is against 2.6.29.2 and not tested, but builds. I can also send
rest of the changes as separate small feature patches as needed.
However, before doing any more work I would like to hear opinions on
this and especially what is wrong with the code or idea...

> And 2), the kernel can help by providing a deadline based scheduler,
> which should make the above easier and less likely to mess up the rest
> of the system. ie. a deadline scheduled application will not exceed its
> allotted budget, unlike a FIFO scheduled app.

Any news on this one?


	- Jussi

[-- Attachment #2: sched-tiny.patch --]
[-- Type: text/x-patch, Size: 4358 bytes --]

diff -urN linux-2.6.29.2.orig/include/linux/sched.h linux-2.6.29.2.new/include/linux/sched.h
--- linux-2.6.29.2.orig/include/linux/sched.h	2009-04-27 20:37:11.000000000 +0300
+++ linux-2.6.29.2.new/include/linux/sched.h	2009-05-11 11:02:26.000000000 +0300
@@ -38,6 +38,7 @@
 #define SCHED_BATCH		3
 /* SCHED_ISO: reserved but not implemented yet */
 #define SCHED_IDLE		5
+#define SCHED_MM		6
 
 #ifdef __KERNEL__
 
diff -urN linux-2.6.29.2.orig/kernel/sched.c linux-2.6.29.2.new/kernel/sched.c
--- linux-2.6.29.2.orig/kernel/sched.c	2009-04-27 20:37:11.000000000 +0300
+++ linux-2.6.29.2.new/kernel/sched.c	2009-05-11 11:02:26.000000000 +0300
@@ -24,6 +24,7 @@
  *  2007-07-01  Group scheduling enhancements by Srivatsa Vaddagiri
  *  2007-11-29  RT balancing improvements by Steven Rostedt, Gregory Haskins,
  *              Thomas Gleixner, Mike Kravetz
+ *  2008-12-22  Multimedia scheduling class by Jussi Laako.
  */
 
 #include <linux/mm.h>
@@ -98,6 +99,14 @@
 #define MAX_USER_PRIO		(USER_PRIO(MAX_PRIO))
 
 /*
+ * User definable priorities for SCHED_MM.
+ */
+#define MM_PRIO_MIN		0
+#define MM_PRIO_MAX		39
+#define INV_MM_PRIO(p)		(39-(p))
+#define STATIC_PRIO(p)		((p)+MAX_RT_PRIO)
+
+/*
  * Helpers for converting nanosecond timing to jiffy resolution
  */
 #define NS_TO_JIFFIES(TIME)	((unsigned long)(TIME) / (NSEC_PER_SEC / HZ))
@@ -160,6 +169,18 @@
 	return rt_policy(p->policy);
 }
 
+static inline int mm_policy(int policy)
+{
+	if (unlikely(policy == SCHED_MM))
+		return 1;
+	return 0;
+}
+
+static inline int task_has_mm_policy(struct task_struct *p)
+{
+	return mm_policy(p->policy);
+}
+
 /*
  * This is the priority-queue data structure of the RT scheduling class:
  */
@@ -5282,6 +5303,7 @@
 	case SCHED_NORMAL:
 	case SCHED_BATCH:
 	case SCHED_IDLE:
+	case SCHED_MM:
 		p->sched_class = &fair_sched_class;
 		break;
 	case SCHED_FIFO:
@@ -5292,6 +5314,8 @@
 
 	p->rt_priority = prio;
 	p->normal_prio = normal_prio(p);
+	if (task_has_mm_policy(p))
+		p->static_prio = prio;
 	/* we are holding p->pi_lock already */
 	p->prio = rt_mutex_getprio(p);
 	set_load_weight(p);
@@ -5329,19 +5353,26 @@
 		policy = oldpolicy = p->policy;
 	else if (policy != SCHED_FIFO && policy != SCHED_RR &&
 			policy != SCHED_NORMAL && policy != SCHED_BATCH &&
-			policy != SCHED_IDLE)
+			policy != SCHED_IDLE && policy != SCHED_MM)
 		return -EINVAL;
 	/*
 	 * Valid priorities for SCHED_FIFO and SCHED_RR are
 	 * 1..MAX_USER_RT_PRIO-1, valid priority for SCHED_NORMAL,
 	 * SCHED_BATCH and SCHED_IDLE is 0.
+	 * SCHED_MM has valid range from MM_PRIO_MIN to MM_PRIO_MAX.
 	 */
-	if (param->sched_priority < 0 ||
-	    (p->mm && param->sched_priority > MAX_USER_RT_PRIO-1) ||
-	    (!p->mm && param->sched_priority > MAX_RT_PRIO-1))
-		return -EINVAL;
-	if (rt_policy(policy) != (param->sched_priority != 0))
-		return -EINVAL;
+	if (mm_policy(policy)) {
+		if (param->sched_priority < MM_PRIO_MIN ||
+		    param->sched_priority > MM_PRIO_MAX)
+			return -EINVAL;
+	} else {
+		if (param->sched_priority < 0 ||
+		    (p->mm && param->sched_priority > MAX_USER_RT_PRIO-1) ||
+		    (!p->mm && param->sched_priority > MAX_RT_PRIO-1))
+			return -EINVAL;
+		if (rt_policy(policy) != (param->sched_priority != 0))
+			return -EINVAL;
+	}
 
 	/*
 	 * Allow unprivileged RT tasks to decrease priority:
@@ -5418,7 +5449,11 @@
 		p->sched_class->put_prev_task(rq, p);
 
 	oldprio = p->prio;
-	__setscheduler(rq, p, policy, param->sched_priority);
+	if (mm_policy(policy))
+		__setscheduler(rq, p, policy,
+			STATIC_PRIO(INV_MM_PRIO(param->sched_priority)));
+	else
+		__setscheduler(rq, p, policy, param->sched_priority);
 
 	if (running)
 		p->sched_class->set_curr_task(rq);
@@ -5563,7 +5598,10 @@
 	if (retval)
 		goto out_unlock;
 
-	lp.sched_priority = p->rt_priority;
+	if (task_has_mm_policy(p))
+		lp.sched_priority = INV_MM_PRIO(USER_PRIO(p->static_prio));
+	else
+		lp.sched_priority = p->rt_priority;
 	read_unlock(&tasklist_lock);
 
 	/*
@@ -5890,6 +5928,9 @@
 	case SCHED_RR:
 		ret = MAX_USER_RT_PRIO-1;
 		break;
+	case SCHED_MM:
+		ret = MM_PRIO_MAX;
+		break;
 	case SCHED_NORMAL:
 	case SCHED_BATCH:
 	case SCHED_IDLE:
@@ -5915,10 +5956,14 @@
 	case SCHED_RR:
 		ret = 1;
 		break;
+	case SCHED_MM:
+		ret = MM_PRIO_MIN;
+		break;
 	case SCHED_NORMAL:
 	case SCHED_BATCH:
 	case SCHED_IDLE:
 		ret = 0;
+		break;
 	}
 	return ret;
 }

  reply	other threads:[~2009-05-11  8:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-29 18:40 [RFC][PATCH] Multimedia scheduling class Jussi Laako
2008-12-30  7:42 ` Peter Zijlstra
2008-12-30  8:39   ` Jussi Laako
2009-01-12  9:55     ` Jussi Laako
2009-01-12 10:28     ` Peter Zijlstra
2009-01-13  9:44       ` Jussi Laako
2009-01-17 12:49         ` James Courtier-Dutton
2009-01-25 23:09           ` Jussi Laako
2009-01-26  7:25             ` Peter Zijlstra
2009-05-11  8:22               ` Jussi Laako [this message]
2009-05-12  5:38                 ` [RFC][PATCH] Multimedia scheduling class, take 2 Artem Bityutskiy
2009-05-12  5:57                 ` Peter Zijlstra
2009-05-12  9:53                   ` Jussi Laako
2009-05-12 15:32                     ` Chris Friesen
2009-05-12 16:34                       ` Jussi Laako
2009-05-12 16:45                         ` Raistlin
2009-05-12 17:38                           ` Jussi Laako
2009-05-12 17:55                           ` Jussi Laako
2009-05-12 17:00                         ` Chris Friesen
2009-05-12 17:53                           ` Jussi Laako
2009-05-12 23:04                             ` Chris Friesen
2009-05-13  6:36                               ` Jussi Laako
2009-05-12 10:07                   ` Jussi Laako
2009-05-12 11:19                     ` Peter Zijlstra
2009-05-12 12:12                       ` Jussi Laako
2009-05-12  9:40                 ` Henrik Austad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A07E044.8040807@sonarnerd.net \
    --to=jussi@sonarnerd.net \
    --cc=James@superbug.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.