linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
@ 2005-01-18 13:01 Con Kolivas
  2005-01-18 14:53 ` Con Kolivas
                   ` (3 more replies)
  0 siblings, 4 replies; 18+ messages in thread
From: Con Kolivas @ 2005-01-18 13:01 UTC (permalink / raw)
  To: linux; +Cc: Ingo Molnar, rlrevell, paul, joq, CK Kernel


[-- Attachment #1.1: Type: text/plain, Size: 2233 bytes --]

This patch for 2.6.11-rc1 provides a method of providing real time
scheduling to unprivileged users which increasingly is desired for
multimedia workloads.

It does this by adding a new scheduling class called SCHED_ISO or
Isochronous scheduling which means "same time" scheduling. This class
does not require superuser privileges and is starvation free. The
scheduling class no. 4 was chosen since there are quite a few userspace
applications already supporting 3 and 4 for SCHED_BATCH and SCHED_ISO
respectively on non-mainline kernels. As a way of immediately providing
support for current userspace apps, any unprivileged user starting an
application requesting SCHED_RR or SCHED_FIFO will be demoted to
SCHED_ISO. This may or may not be worth removing later.

The SCHED_ISO class runs as SCHED_RR effectively at a priority just
above all SCHED_NORMAL tasks and below all true real time tasks. Once a
cpu usage limit is exceeded by tasks of this class (per cpu), SCHED_ISO
tasks will then run as SCHED_NORMAL until the cpu usage drops to 90% of
the cpu limit.

By default the cpu limit is set to 70% which literature suggests should
provide good real time behaviour for most applications without gross
unfairness. This cpu limit is calculated as a decaying average over 5
seconds. These limits are configurable with the tunables
/proc/sys/kernel/iso_cpu
/proc/sys/kernel/iso_period

iso_cpu can be set to 100 which would allow all unprivileged users
access to unrestricted SCHED_RR behaviour. OSX provides a similar class
to SCHED_ISO and uses 90% as its cpu limit.

The sysrq-n combination which converts all user real-time tasks to
SCHED_NORMAL also will affect SCHED_ISO tasks.

Currently the round robin interval is set to 10ms which is a cache
friendly timeslice. It may be worth making this configurable or smaller,
and it would also be possible to implement SCHED_ISO of a FIFO nature as
well.

For testing, the userspace tool schedtool available here:
http://freequaos.host.sk/schedtool/
can be used as a wrapper to start SCHED_ISO tasks
schedtool -I -e xmms
for example

Patch also available here:
http://ck.kolivas.org/patches/SCHED_ISO/

Comments and testing welcome.

Signed-off-by: Con Kolivas <kernel@kolivas.org>


[-- Attachment #1.2: 2.6.11-rc1-iso-0501182249.diff --]
[-- Type: text/x-diff, Size: 16226 bytes --]

Index: linux-2.6.11-rc1/include/linux/init_task.h
===================================================================
--- linux-2.6.11-rc1.orig/include/linux/init_task.h	2005-01-16 22:43:47.000000000 +1100
+++ linux-2.6.11-rc1/include/linux/init_task.h	2005-01-16 22:45:23.000000000 +1100
@@ -80,6 +80,7 @@
 	.mm		= NULL,						\
 	.active_mm	= &init_mm,					\
 	.run_list	= LIST_HEAD_INIT(tsk.run_list),			\
+	.iso_list	= LIST_HEAD_INIT(tsk.iso_list),			\
 	.time_slice	= HZ,						\
 	.tasks		= LIST_HEAD_INIT(tsk.tasks),			\
 	.ptrace_children= LIST_HEAD_INIT(tsk.ptrace_children),		\
Index: linux-2.6.11-rc1/include/linux/sched.h
===================================================================
--- linux-2.6.11-rc1.orig/include/linux/sched.h	2005-01-16 22:43:47.000000000 +1100
+++ linux-2.6.11-rc1/include/linux/sched.h	2005-01-18 22:48:05.000000000 +1100
@@ -130,6 +130,18 @@
 #define SCHED_NORMAL		0
 #define SCHED_FIFO		1
 #define SCHED_RR		2
+/* policy 3 reserved for SCHED_BATCH */
+#define SCHED_ISO		4
+
+extern int iso_cpu, iso_period;
+
+#define SCHED_RANGE(policy)	((policy) == SCHED_NORMAL || \
+				(policy) == SCHED_FIFO || \
+				(policy) == SCHED_RR || \
+				(policy) == SCHED_ISO)
+
+#define SCHED_RT(policy)	((policy) == SCHED_FIFO || \
+				(policy) == SCHED_RR)
 
 struct sched_param {
 	int sched_priority;
@@ -359,6 +371,7 @@
 #define MAX_PRIO		(MAX_RT_PRIO + 40)
 
 #define rt_task(p)		(unlikely((p)->prio < MAX_RT_PRIO))
+#define iso_task(p)		(unlikely((p)->policy == SCHED_ISO))
 
 /*
  * Some day this will be a full-fledged user tracking system..
@@ -536,6 +549,7 @@
 
 	int prio, static_prio;
 	struct list_head run_list;
+	struct list_head iso_list;
 	prio_array_t *array;
 
 	unsigned long sleep_avg;
Index: linux-2.6.11-rc1/include/linux/sysctl.h
===================================================================
--- linux-2.6.11-rc1.orig/include/linux/sysctl.h	2005-01-16 22:43:47.000000000 +1100
+++ linux-2.6.11-rc1/include/linux/sysctl.h	2005-01-16 22:45:23.000000000 +1100
@@ -135,6 +135,8 @@
 	KERN_HZ_TIMER=65,	/* int: hz timer on or off */
 	KERN_UNKNOWN_NMI_PANIC=66, /* int: unknown nmi panic flag */
 	KERN_BOOTLOADER_TYPE=67, /* int: boot loader type */
+	KERN_ISO_CPU=68,	/* int: cpu% allowed by SCHED_ISO class */
+	KERN_ISO_PERIOD=69,	/* int: seconds over which SCHED_ISO cpu is decayed */
 };
 
 
Index: linux-2.6.11-rc1/kernel/sched.c
===================================================================
--- linux-2.6.11-rc1.orig/kernel/sched.c	2005-01-16 22:43:47.000000000 +1100
+++ linux-2.6.11-rc1/kernel/sched.c	2005-01-18 22:48:47.000000000 +1100
@@ -149,9 +149,6 @@
 	(JIFFIES_TO_NS(MAX_SLEEP_AVG * \
 		(MAX_BONUS / 2 + DELTA((p)) + 1) / MAX_BONUS - 1))
 
-#define TASK_PREEMPTS_CURR(p, rq) \
-	((p)->prio < (rq)->curr->prio)
-
 /*
  * task_timeslice() scales user-nice values [ -20 ... 0 ... 19 ]
  * to time slice values: [800ms ... 100ms ... 5ms]
@@ -171,6 +168,10 @@
 	else
 		return SCALE_PRIO(DEF_TIMESLICE, p->static_prio);
 }
+
+int iso_cpu = 70;	/* The soft %cpu limit on SCHED_ISO tasks */
+int iso_period = 5;	/* The time over which SCHED_ISO cpu decays */
+
 #define task_hot(p, now, sd) ((long long) ((now) - (p)->last_ran)	\
 				< (long long) (sd)->cache_hot_time)
 
@@ -206,6 +207,16 @@
 #ifdef CONFIG_SMP
 	unsigned long cpu_load;
 #endif
+	unsigned long iso_ticks;
+	struct list_head iso_queue;
+	int iso_refractory;
+	/* 
+	 * Refractory is the flag that we've hit the maximum iso cpu and are
+	 * in the refractory period where SCHED_ISO tasks can only run as
+	 * SCHED_NORMAL until their cpu usage drops to 90% of their iso_cpu
+	 * limit.
+	 */
+
 	unsigned long long nr_switches;
 
 	/*
@@ -297,6 +308,19 @@
 # define task_running(rq, p)		((rq)->curr == (p))
 #endif
 
+static inline int task_preempts_curr(task_t *p, runqueue_t *rq)
+{
+	if ((!iso_task(p) && !iso_task(rq->curr)) || rq->iso_refractory ||
+		rt_task(p) || rt_task(rq->curr)) {
+			if (p->prio < rq->curr->prio)
+				return 1;
+			return 0;
+	}
+	if (iso_task(p) && !iso_task(rq->curr))
+		return 1;
+	return 0;
+}
+
 /*
  * task_rq_lock - lock the runqueue a given task resides on and disable
  * interrupts.  Note the ordering: we can safely lookup the task_rq without
@@ -560,17 +584,40 @@
 #define sched_info_switch(t, next)	do { } while (0)
 #endif /* CONFIG_SCHEDSTATS */
 
+static inline int iso_queued(runqueue_t *rq)
+{
+	return !list_empty(&rq->iso_queue);
+}
+
+static inline void dequeue_iso_task(struct task_struct *p)
+{
+	list_del_init(&p->iso_list);
+}
+
 /*
  * Adding/removing a task to/from a priority array:
  */
 static void dequeue_task(struct task_struct *p, prio_array_t *array)
 {
 	array->nr_active--;
+	if (iso_task(p))
+		dequeue_iso_task(p);
 	list_del(&p->run_list);
 	if (list_empty(array->queue + p->prio))
 		__clear_bit(p->prio, array->bitmap);
 }
 
+/*
+ * SCHED_ISO tasks are queued at both runqueues. Their actual priority is
+ * either better than SCHED_NORMAL if below starvation limits, or
+ * the underlying SCHED_NORMAL dynamic priority.
+ */
+static void enqueue_iso_task(struct task_struct *p)
+{
+	runqueue_t *rq = task_rq(p);
+	list_add_tail(&p->iso_list, &rq->iso_queue);
+}
+
 static void enqueue_task(struct task_struct *p, prio_array_t *array)
 {
 	sched_info_queued(p);
@@ -578,6 +625,14 @@
 	__set_bit(p->prio, array->bitmap);
 	array->nr_active++;
 	p->array = array;
+	if (iso_task(p))
+		enqueue_iso_task(p);
+}
+
+static void requeue_iso_task(struct task_struct *p)
+{
+	runqueue_t *rq = task_rq(p);
+	list_move_tail(&p->iso_list, &rq->iso_queue);
 }
 
 /*
@@ -587,6 +642,8 @@
 static void requeue_task(struct task_struct *p, prio_array_t *array)
 {
 	list_move_tail(&p->run_list, array->queue + p->prio);
+	if (iso_task(p))
+		requeue_iso_task(p);
 }
 
 static inline void enqueue_task_head(struct task_struct *p, prio_array_t *array)
@@ -1101,7 +1158,7 @@
 	 */
 	activate_task(p, rq, cpu == this_cpu);
 	if (!sync || cpu != this_cpu) {
-		if (TASK_PREEMPTS_CURR(p, rq))
+		if (task_preempts_curr(p, rq))
 			resched_task(rq->curr);
 	}
 	success = 1;
@@ -1146,6 +1203,7 @@
 	 */
 	p->state = TASK_RUNNING;
 	INIT_LIST_HEAD(&p->run_list);
+	INIT_LIST_HEAD(&p->iso_list);
 	p->array = NULL;
 	spin_lock_init(&p->switch_lock);
 #ifdef CONFIG_SCHEDSTATS
@@ -1235,6 +1293,8 @@
 				p->array = current->array;
 				p->array->nr_active++;
 				rq->nr_running++;
+				if (iso_task(p))
+					enqueue_iso_task(p);
 			}
 			set_need_resched();
 		} else
@@ -1257,7 +1317,7 @@
 		p->timestamp = (p->timestamp - this_rq->timestamp_last_tick)
 					+ rq->timestamp_last_tick;
 		__activate_task(p, rq);
-		if (TASK_PREEMPTS_CURR(p, rq))
+		if (task_preempts_curr(p, rq))
 			resched_task(rq->curr);
 
 		schedstat_inc(rq, wunt_moved);
@@ -1634,7 +1694,7 @@
 	 * Note that idle threads have a prio of MAX_PRIO, for this test
 	 * to be always true for them.
 	 */
-	if (TASK_PREEMPTS_CURR(p, this_rq))
+	if (task_preempts_curr(p, this_rq))
 		resched_task(this_rq->curr);
 }
 
@@ -2392,6 +2452,39 @@
 		cpustat->steal = cputime64_add(cpustat->steal, steal64);
 }
 
+static inline int inc_iso_ticks(runqueue_t *rq, task_t *p)
+{
+	int ret = 0;
+	if (rq->iso_ticks < (iso_period * HZ * 100 - 99))
+		rq->iso_ticks += 100;
+	spin_lock(&rq->lock);
+	if (!rq->iso_refractory && (rq->iso_ticks /
+		((iso_period * HZ) + 1) > iso_cpu)) {
+			rq->iso_refractory = 1;
+			if (iso_queued(rq))
+				ret = 1;
+		}
+	spin_unlock(&rq->lock);
+	return ret;
+}
+
+static inline int dec_iso_ticks(runqueue_t *rq, task_t *p)
+{
+	int ret = 0;
+	if (rq->iso_ticks) 
+		rq->iso_ticks = rq->iso_ticks * (iso_period * HZ - 1) /
+			(iso_period * HZ);
+	spin_lock(&rq->lock);
+	if (rq->iso_refractory && (rq->iso_ticks /
+		((iso_period * HZ) + 1) < (iso_cpu * 9 / 10))) {
+			rq->iso_refractory = 0;
+			if (iso_queued(rq)) 
+				ret = 1;
+	}
+	spin_unlock(&rq->lock);
+	return ret;
+}
+
 /*
  * This function gets called by the timer code, with HZ frequency.
  * We call it with interrupts disabled.
@@ -2404,8 +2497,13 @@
 	int cpu = smp_processor_id();
 	runqueue_t *rq = this_rq();
 	task_t *p = current;
+	int iso_change;
 
 	rq->timestamp_last_tick = sched_clock();
+	if (iso_task(p) && !rq->iso_refractory)
+		iso_change = inc_iso_ticks(rq, p);
+	else 
+		iso_change = dec_iso_ticks(rq, p);
 
 	if (p == rq->idle) {
 		if (wake_priority_sleeper(rq))
@@ -2420,6 +2518,7 @@
 		goto out;
 	}
 	spin_lock(&rq->lock);
+
 	/*
 	 * The task was running during this tick - update the
 	 * time slice counter. Note: we do not update a thread's
@@ -2442,6 +2541,39 @@
 		}
 		goto out_unlock;
 	}
+
+	if (unlikely(iso_change)) {
+		/*
+		 * A SCHED_ISO task was running and the soft cpu limit
+		 * was hit, or SCHED_ISO task(s) are waiting and the 
+		 * refractory period has ended. Reschedule to start ISO
+		 * tasks as SCHED_NORMAL in the former case and to allow
+		 * SCHED_ISO tasks to preempt in the latter.
+		 */
+		set_tsk_need_resched(p);
+		dequeue_task(p, rq->active);
+		p->prio = effective_prio(p);
+		p->time_slice = task_timeslice(p);
+		p->first_time_slice = 0;
+		enqueue_task(p, rq->active);
+		goto out_unlock;
+	}
+
+	if (iso_task(p) && !rq->iso_refractory) {
+		if (!--p->time_slice) {
+			p->time_slice = task_timeslice(p);
+			p->first_time_slice = 0;
+			set_tsk_need_resched(p);
+
+			/* put it at the end of the queue: */
+			requeue_task(p, rq->active);
+		} else if (!(p->time_slice % GRANULARITY)) {
+			requeue_task(p, rq->active);
+			set_tsk_need_resched(p);
+		}
+		goto out_unlock;
+	}
+
 	if (!--p->time_slice) {
 		dequeue_task(p, rq->active);
 		set_tsk_need_resched(p);
@@ -2489,6 +2621,30 @@
 	rebalance_tick(cpu, rq, NOT_IDLE);
 }
 
+static inline int iso_ready(runqueue_t *rq)
+{
+	if (iso_queued(rq) && !rq->iso_refractory)
+		return 1;
+	return 0;
+}
+
+/*
+ * When a SCHED_ISO task is ready to be scheduled, we re-queue it with an
+ * effective prio of MAX_RT_PRIO for userspace to know its relative prio.
+ */
+static task_t* queue_iso(runqueue_t *rq, prio_array_t *array)
+{
+	task_t *p = list_entry(rq->iso_queue.next, task_t, iso_list);
+	prio_array_t *old_array = p->array;
+	list_del(&p->run_list);
+	if (list_empty(old_array->queue + p->prio))
+		__clear_bit(p->prio, old_array->bitmap);
+	p->prio = MAX_RT_PRIO;
+	list_add_tail(&p->run_list, array->queue + p->prio);
+	__set_bit(p->prio, array->bitmap);
+	return p;
+}
+
 #ifdef CONFIG_SCHED_SMT
 static inline void wake_sleeping_dependent(int this_cpu, runqueue_t *this_rq)
 {
@@ -2540,7 +2696,7 @@
 	struct sched_domain *sd = this_rq->sd;
 	cpumask_t sibling_map;
 	prio_array_t *array;
-	int ret = 0, i;
+	int ret = 0, i, idx;
 	task_t *p;
 
 	if (!(sd->flags & SD_SHARE_CPUPOWER))
@@ -2567,8 +2723,11 @@
 		array = this_rq->expired;
 	BUG_ON(!array->nr_active);
 
-	p = list_entry(array->queue[sched_find_first_bit(array->bitmap)].next,
-		task_t, run_list);
+	idx = sched_find_first_bit(array->bitmap);
+	if (unlikely(iso_ready(this_rq) && idx >= MAX_RT_PRIO))
+		p = queue_iso(this_rq, array);
+	else
+		p = list_entry(array->queue[idx].next, task_t, run_list);
 
 	for_each_cpu_mask(i, sibling_map) {
 		runqueue_t *smt_rq = cpu_rq(i);
@@ -2584,7 +2743,7 @@
 		 */
 		if (((smt_curr->time_slice * (100 - sd->per_cpu_gain) / 100) >
 			task_timeslice(p) || rt_task(smt_curr)) &&
-			p->mm && smt_curr->mm && !rt_task(p))
+			p->mm && smt_curr->mm && !rt_task(p) && !iso_task(p))
 				ret = 1;
 
 		/*
@@ -2594,8 +2753,9 @@
 		 */
 		if ((((p->time_slice * (100 - sd->per_cpu_gain) / 100) >
 			task_timeslice(smt_curr) || rt_task(p)) &&
-			smt_curr->mm && p->mm && !rt_task(smt_curr)) ||
-			(smt_curr == smt_rq->idle && smt_rq->nr_running))
+			smt_curr->mm && p->mm && !rt_task(smt_curr) &&
+			!iso_task(smt_curr)) || (smt_curr == smt_rq->idle &&
+			smt_rq->nr_running))
 				resched_task(smt_curr);
 	}
 out_unlock:
@@ -2767,8 +2927,12 @@
 		schedstat_inc(rq, sched_noswitch);
 
 	idx = sched_find_first_bit(array->bitmap);
-	queue = array->queue + idx;
-	next = list_entry(queue->next, task_t, run_list);
+	if (unlikely(iso_ready(rq) && idx >= MAX_RT_PRIO))
+		next = queue_iso(rq, array);
+	else {
+		queue = array->queue + idx;
+		next = list_entry(queue->next, task_t, run_list);
+	}
 
 	if (!rt_task(next) && next->activated > 0) {
 		unsigned long long delta = now - next->timestamp;
@@ -3213,7 +3377,7 @@
 	BUG_ON(p->array);
 	p->policy = policy;
 	p->rt_priority = prio;
-	if (policy != SCHED_NORMAL)
+	if (SCHED_RT(policy))
 		p->prio = MAX_USER_RT_PRIO-1 - p->rt_priority;
 	else
 		p->prio = p->static_prio;
@@ -3238,9 +3402,8 @@
 	/* double check policy once rq lock held */
 	if (policy < 0)
 		policy = oldpolicy = p->policy;
-	else if (policy != SCHED_FIFO && policy != SCHED_RR &&
-				policy != SCHED_NORMAL)
-			return -EINVAL;
+	else if (!SCHED_RANGE(policy))
+		return -EINVAL;
 	/*
 	 * Valid priorities for SCHED_FIFO and SCHED_RR are
 	 * 1..MAX_USER_RT_PRIO-1, valid priority for SCHED_NORMAL is 0.
@@ -3248,12 +3411,16 @@
 	if (param->sched_priority < 0 ||
 	    param->sched_priority > MAX_USER_RT_PRIO-1)
 		return -EINVAL;
-	if ((policy == SCHED_NORMAL) != (param->sched_priority == 0))
+	if ((!SCHED_RT(policy)) != (param->sched_priority == 0))
 		return -EINVAL;
 
-	if ((policy == SCHED_FIFO || policy == SCHED_RR) &&
-	    !capable(CAP_SYS_NICE))
-		return -EPERM;
+	if (SCHED_RT(policy) && !capable(CAP_SYS_NICE))
+		/*
+		 * If the caller requested an RT policy without having the
+		 * necessary rights, we downgrade the policy to SCHED_ISO.
+		 * Temporary hack for testing.
+		 */
+		policy = SCHED_ISO;
 	if ((current->euid != p->euid) && (current->euid != p->uid) &&
 	    !capable(CAP_SYS_NICE))
 		return -EPERM;
@@ -3287,7 +3454,7 @@
 		if (task_running(rq, p)) {
 			if (p->prio > oldprio)
 				resched_task(rq->curr);
-		} else if (TASK_PREEMPTS_CURR(p, rq))
+		} else if (task_preempts_curr(p, rq))
 			resched_task(rq->curr);
 	}
 	task_rq_unlock(rq, &flags);
@@ -3714,6 +3881,7 @@
 		ret = MAX_USER_RT_PRIO-1;
 		break;
 	case SCHED_NORMAL:
+	case SCHED_ISO:
 		ret = 0;
 		break;
 	}
@@ -3737,6 +3905,7 @@
 		ret = 1;
 		break;
 	case SCHED_NORMAL:
+	case SCHED_ISO:
 		ret = 0;
 	}
 	return ret;
@@ -4010,7 +4179,7 @@
 				+ rq_dest->timestamp_last_tick;
 		deactivate_task(p, rq_src);
 		activate_task(p, rq_dest, 0);
-		if (TASK_PREEMPTS_CURR(p, rq_dest))
+		if (task_preempts_curr(p, rq_dest))
 			resched_task(rq_dest->curr);
 	}
 
@@ -4792,6 +4961,7 @@
 		rq->active = rq->arrays;
 		rq->expired = rq->arrays + 1;
 		rq->best_expired_prio = MAX_PRIO;
+		rq->iso_refractory = rq->iso_ticks = 0;
 
 #ifdef CONFIG_SMP
 		rq->sd = &sched_domain_dummy;
@@ -4812,6 +4982,7 @@
 			// delimiter for bitsearch
 			__set_bit(MAX_PRIO, array->bitmap);
 		}
+		INIT_LIST_HEAD(&rq->iso_queue);
 	}
 
 	/*
@@ -4861,7 +5032,7 @@
 
 	read_lock_irq(&tasklist_lock);
 	for_each_process (p) {
-		if (!rt_task(p))
+		if (!rt_task(p) && !iso_task(p))
 			continue;
 
 		rq = task_rq_lock(p, &flags);
Index: linux-2.6.11-rc1/kernel/sysctl.c
===================================================================
--- linux-2.6.11-rc1.orig/kernel/sysctl.c	2005-01-16 22:43:47.000000000 +1100
+++ linux-2.6.11-rc1/kernel/sysctl.c	2005-01-16 22:45:23.000000000 +1100
@@ -219,6 +219,11 @@
 	{ .ctl_name = 0 }
 };
 
+/* Constants for minimum and maximum testing in vm_table.
+   We use these as one-element integer vectors. */
+static int zero;
+static int one_hundred = 100;
+
 static ctl_table kern_table[] = {
 	{
 		.ctl_name	= KERN_OSTYPE,
@@ -633,15 +638,28 @@
 		.proc_handler	= &proc_dointvec,
 	},
 #endif
+	{
+		.ctl_name	= KERN_ISO_CPU,
+		.procname	= "iso_cpu",
+		.data		= &iso_cpu,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec_minmax,
+		.strategy	= &sysctl_intvec,
+		.extra1		= &zero,
+		.extra2		= &one_hundred,
+	},
+	{
+		.ctl_name	= KERN_ISO_PERIOD,
+		.procname	= "iso_period",
+		.data		= &iso_period,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
 	{ .ctl_name = 0 }
 };
 
-/* Constants for minimum and maximum testing in vm_table.
-   We use these as one-element integer vectors. */
-static int zero;
-static int one_hundred = 100;
-
-
 static ctl_table vm_table[] = {
 	{
 		.ctl_name	= VM_OVERCOMMIT_MEMORY,





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-18 13:01 [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling Con Kolivas
@ 2005-01-18 14:53 ` Con Kolivas
  2005-01-18 15:45 ` [ck] " Cal
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 18+ messages in thread
From: Con Kolivas @ 2005-01-18 14:53 UTC (permalink / raw)
  Cc: linux, CK Kernel

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

Con Kolivas wrote:
> This patch for 2.6.11-rc1 provides a method of providing real time
> scheduling to unprivileged users which increasingly is desired for
> multimedia workloads.

I should have mentioned. Many thanks to Alex Nyberg for generous 
debugging help.

Cheers,
Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-18 13:01 [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling Con Kolivas
  2005-01-18 14:53 ` Con Kolivas
@ 2005-01-18 15:45 ` Cal
  2005-01-18 15:53   ` Con Kolivas
  2005-01-18 16:17   ` Jack O'Quin
  2005-01-19  5:26 ` utz
  2005-01-19  6:54 ` Jack O'Quin
  3 siblings, 2 replies; 18+ messages in thread
From: Cal @ 2005-01-18 15:45 UTC (permalink / raw)
  To: Con Kolivas; +Cc: linux, CK Kernel, joq, rlrevell, paul

Con Kolivas wrote:
> Comments and testing welcome.

There's a collection of test summaries from jack_test3.2 runs at
<http://www.graggrag.com/ck-tests/ck-tests-0501182249.txt>

Tests were run with iso_cpu at 70, 90, 99, 100, each test was run twice. 
The discrepancies between consecutive runs (with same parameters) is 
puzzling.  Also recorded were tests with SCHED_FIFO and SCHED_RR.

Before drawing any hardball conclusions, verification of the results 
would be nice. At first glance, it does seem that we still have that 
fateful gap between "harm minimisation" (policy) and "zero tolerance" 
(audio reality requirement).

cheers, Cal

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-18 15:45 ` [ck] " Cal
@ 2005-01-18 15:53   ` Con Kolivas
  2005-01-18 16:23     ` Jack O'Quin
  2005-01-18 16:17   ` Jack O'Quin
  1 sibling, 1 reply; 18+ messages in thread
From: Con Kolivas @ 2005-01-18 15:53 UTC (permalink / raw)
  To: hihone; +Cc: linux, CK Kernel, joq, rlrevell, paul

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

Cal wrote:
> Con Kolivas wrote:
> 
>> Comments and testing welcome.
> 
> 
> There's a collection of test summaries from jack_test3.2 runs at
> <http://www.graggrag.com/ck-tests/ck-tests-0501182249.txt>
> 
> Tests were run with iso_cpu at 70, 90, 99, 100, each test was run twice. 
> The discrepancies between consecutive runs (with same parameters) is 
> puzzling.  Also recorded were tests with SCHED_FIFO and SCHED_RR.
> 
> Before drawing any hardball conclusions, verification of the results 
> would be nice. At first glance, it does seem that we still have that 
> fateful gap between "harm minimisation" (policy) and "zero tolerance" 
> (audio reality requirement).

Thanks.

SCHED_ISO
/proc/sys/kernel/iso_cpu . . .: 70
/proc/sys/kernel/iso_period . : 5
XRUN Count  . . . . . . . . . :   110

vs

SCHED_FIFO
XRUN Count  . . . . . . . . . :   114
XRUN Count  . . . . . . . . . :   187

vs

SCHED_RR
XRUN Count  . . . . . . . . . :     0
XRUN Count  . . . . . . . . . :     0

Something funny going on here... You had more xruns with SCHED_FIFO than 
the default SCHED_ISO settings, and had none with SCHED_RR. Even in the 
absence of the SCHED_ISO results, the other results dont make a lot of 
sense.

Con

P.S. If you're running on SMP it may be worth booting on UP or using cpu 
affinity (schedtool -a 0x1 will bind you to 1st cpu only) and see what 
effect that is having. There are some interesting things that can 
adversely affect latency on SMP.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-18 15:45 ` [ck] " Cal
  2005-01-18 15:53   ` Con Kolivas
@ 2005-01-18 16:17   ` Jack O'Quin
  2005-01-19  2:02     ` Lee Revell
  1 sibling, 1 reply; 18+ messages in thread
From: Jack O'Quin @ 2005-01-18 16:17 UTC (permalink / raw)
  To: hihone; +Cc: Con Kolivas, linux, CK Kernel, rlrevell, paul

Cal <hihone@bigpond.net.au> writes:

> There's a collection of test summaries from jack_test3.2 runs at
> <http://www.graggrag.com/ck-tests/ck-tests-0501182249.txt>
>
> Tests were run with iso_cpu at 70, 90, 99, 100, each test was run
> twice. The discrepancies between consecutive runs (with same
> parameters) is puzzling.  Also recorded were tests with SCHED_FIFO and
> SCHED_RR.

It's probably suffering from some of the same problems of thread
granularity we saw running nice --20.  It looks like you used
schedtool to start jackd.  IIUC, that will cause all jackd processes
to run in the specified scheduling class.  JACK is carefully written
not to do that.  Did you also use schedtool to start all the clients?

I think your puzzling discrepancies are probably due to interference
from non-realtime JACK threads running at elevated priority.

> Before drawing any hardball conclusions, verification of the results
> would be nice. At first glance, it does seem that we still have that
> fateful gap between "harm minimisation" (policy) and "zero tolerance"
> (audio reality requirement).

I still have not found time to run Con's latest version.  I've been
too busy trying to hack JACK into working with nice(-20), which has
turned out to be quite difficult.  The interfaces we need don't work,
and the ones that do are not what we need.  :-(

I believe Con's latest sched patch should work fine with the normal
jack_test3.2 using the -R option of jackd.  That should produce more
consistent results.
-- 
  joq

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-18 15:53   ` Con Kolivas
@ 2005-01-18 16:23     ` Jack O'Quin
  0 siblings, 0 replies; 18+ messages in thread
From: Jack O'Quin @ 2005-01-18 16:23 UTC (permalink / raw)
  To: Con Kolivas; +Cc: hihone, linux, CK Kernel, rlrevell, paul

Con Kolivas <kernel@kolivas.org> writes:

> Cal wrote:
>
> SCHED_ISO
> /proc/sys/kernel/iso_cpu . . .: 70
> /proc/sys/kernel/iso_period . : 5
> XRUN Count  . . . . . . . . . :   110
>
> vs
>
> SCHED_FIFO
> XRUN Count  . . . . . . . . . :   114
> XRUN Count  . . . . . . . . . :   187
>
> vs
>
> SCHED_RR
> XRUN Count  . . . . . . . . . :     0
> XRUN Count  . . . . . . . . . :     0
>
> Something funny going on here... You had more xruns with SCHED_FIFO
> than the default SCHED_ISO settings, and had none with SCHED_RR. Even
> in the absence of the SCHED_ISO results, the other results dont make a
> lot of sense.

Actually it makes perfect sense.  Running non-realtime JACK threads
SCHED_FIFO will do the most harm.  The others less.

I predict that using normal jackd -R (without schedtool) will produce
the same results running SCHED_FIFO and SCHED_ISO (within the normal
variance).

I think schedtool is too blunt and instrument for making these
measurements.
-- 
  joq

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-18 16:17   ` Jack O'Quin
@ 2005-01-19  2:02     ` Lee Revell
  2005-01-19  2:08       ` Con Kolivas
  0 siblings, 1 reply; 18+ messages in thread
From: Lee Revell @ 2005-01-19  2:02 UTC (permalink / raw)
  To: Jack O'Quin; +Cc: hihone, Con Kolivas, linux, CK Kernel, paul

On Tue, 2005-01-18 at 10:17 -0600, Jack O'Quin wrote:
> Cal <hihone@bigpond.net.au> writes:
> 
> > There's a collection of test summaries from jack_test3.2 runs at
> > <http://www.graggrag.com/ck-tests/ck-tests-0501182249.txt>
> >
> > Tests were run with iso_cpu at 70, 90, 99, 100, each test was run
> > twice. The discrepancies between consecutive runs (with same
> > parameters) is puzzling.  Also recorded were tests with SCHED_FIFO and
> > SCHED_RR.
> 
> It's probably suffering from some of the same problems of thread
> granularity we saw running nice --20.  It looks like you used
> schedtool to start jackd.  IIUC, that will cause all jackd processes
> to run in the specified scheduling class.  JACK is carefully written
> not to do that.  Did you also use schedtool to start all the clients?
> 
> I think your puzzling discrepancies are probably due to interference
> from non-realtime JACK threads running at elevated priority.

Isn't this going to be a showstopper?  If I understand the scheduler
correctly, a nice -20 task is not guaranteed to preempt a nice -19 task,
if the scheduler decides that one is more CPU bound than the other and
lowers its dynamic priority.  The design of JACK, however, requires the
higher priority threads to *always* preempt the lower ones.

Lee


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-19  2:02     ` Lee Revell
@ 2005-01-19  2:08       ` Con Kolivas
  0 siblings, 0 replies; 18+ messages in thread
From: Con Kolivas @ 2005-01-19  2:08 UTC (permalink / raw)
  To: Lee Revell; +Cc: Jack O'Quin, hihone, linux, CK Kernel, paul

Lee Revell wrote:
> On Tue, 2005-01-18 at 10:17 -0600, Jack O'Quin wrote:
> 
>>Cal <hihone@bigpond.net.au> writes:
>>
>>
>>>There's a collection of test summaries from jack_test3.2 runs at
>>><http://www.graggrag.com/ck-tests/ck-tests-0501182249.txt>
>>>
>>>Tests were run with iso_cpu at 70, 90, 99, 100, each test was run
>>>twice. The discrepancies between consecutive runs (with same
>>>parameters) is puzzling.  Also recorded were tests with SCHED_FIFO and
>>>SCHED_RR.
>>
>>It's probably suffering from some of the same problems of thread
>>granularity we saw running nice --20.  It looks like you used
>>schedtool to start jackd.  IIUC, that will cause all jackd processes
>>to run in the specified scheduling class.  JACK is carefully written
>>not to do that.  Did you also use schedtool to start all the clients?
>>
>>I think your puzzling discrepancies are probably due to interference
>>from non-realtime JACK threads running at elevated priority.
> 
> 
> Isn't this going to be a showstopper?  If I understand the scheduler
> correctly, a nice -20 task is not guaranteed to preempt a nice -19 task,
> if the scheduler decides that one is more CPU bound than the other and
> lowers its dynamic priority.  The design of JACK, however, requires the
> higher priority threads to *always* preempt the lower ones.

The point was the application was started in a manner which would not 
make best use of this policy. The way it was started put everything 
under the same policy, and had equal performance with doing the same 
thing as SCHED_FIFO. So if it's a showstopper for SCHED_ISO then it is a 
showstopper for SCHED_FIFO. Which is, of course, not the case. The test 
needs to be performed again with the rt threads running SCHED_ISO, which 
  Jack has pointed out is trivial. Nice -n -20 on the other hand will 
suffer from this problem even if only the real time thread was run at -20.

Cheers,
Con

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-18 13:01 [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling Con Kolivas
  2005-01-18 14:53 ` Con Kolivas
  2005-01-18 15:45 ` [ck] " Cal
@ 2005-01-19  5:26 ` utz
  2005-01-19  5:31   ` Con Kolivas
  2005-01-19 14:01   ` Con Kolivas
  2005-01-19  6:54 ` Jack O'Quin
  3 siblings, 2 replies; 18+ messages in thread
From: utz @ 2005-01-19  5:26 UTC (permalink / raw)
  To: Con Kolivas; +Cc: LKML, Ingo Molnar, rlrevell, paul, joq, CK Kernel

Hi Con

I just played with your SCHED_ISO patch and found a simple way to crash
my machine.

I'm running this as unprivileged user with SCHED_ISO:

main ()
{
        while(1) {
                sched_yield();
        }
}

The system hangs about 3s and then reboots itself.
2.6.11-rc1 + 2.6.11-rc1-iso-0501182249 on an UP Athlon XP.

With real SCHED_FIFO it just lockup the system.
 
utz



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-19  5:26 ` utz
@ 2005-01-19  5:31   ` Con Kolivas
  2005-01-19 14:01   ` Con Kolivas
  1 sibling, 0 replies; 18+ messages in thread
From: Con Kolivas @ 2005-01-19  5:31 UTC (permalink / raw)
  To: utz; +Cc: LKML, Ingo Molnar, rlrevell, paul, joq, CK Kernel

utz wrote:
> Hi Con
> 
> I just played with your SCHED_ISO patch and found a simple way to crash
> my machine.
> 
> I'm running this as unprivileged user with SCHED_ISO:
> 
> main ()
> {
>         while(1) {
>                 sched_yield();
>         }
> }
> 
> The system hangs about 3s and then reboots itself.
> 2.6.11-rc1 + 2.6.11-rc1-iso-0501182249 on an UP Athlon XP.
> 
> With real SCHED_FIFO it just lockup the system.

Thanks I'll look into it.

Cheers,
Con

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-18 13:01 [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling Con Kolivas
                   ` (2 preceding siblings ...)
  2005-01-19  5:26 ` utz
@ 2005-01-19  6:54 ` Jack O'Quin
  2005-01-19  7:56   ` Con Kolivas
  2005-01-19  9:33   ` Con Kolivas
  3 siblings, 2 replies; 18+ messages in thread
From: Jack O'Quin @ 2005-01-19  6:54 UTC (permalink / raw)
  To: Con Kolivas; +Cc: linux, Ingo Molnar, rlrevell, paul, CK Kernel

Con Kolivas <kernel@kolivas.org> writes:

> This patch for 2.6.11-rc1 provides a method of providing real time
> scheduling to unprivileged users which increasingly is desired for
> multimedia workloads.

I ran some jack_test3.2 runs with this, using all the default
settings.  The results of three runs differ quite significantly for no
obvious reason.  I can't figure out why the DSP load should vary so
much.  

These may be bogus results.  It looks like a libjack bug sometimes
causes clients to crash when deactivating.  I will investigate more
tomorrow, and come up with a fix.

For comparison, I also made a couple of runs using the realtime-lsm to
grant SCHED_FIFO privileges.  There was some variablility, but nowhere
near as much (and no crashes).  I used schedtool to verify that the
jackd threads actually have the expected scheduler type.

============================================
Unprivileged, realtime threads are SCHED_ISO
============================================

*** Terminated Tue Jan 18 23:54:55 CST 2005 ***
************* SUMMARY RESULT ****************
Total seconds ran . . . . . . :   300
Number of clients . . . . . . :    20
Ports per client  . . . . . . :     4
Frames per buffer . . . . . . :    64
*********************************************
Timeout Count . . . . . . . . :(    3)          (   14)         (    2)        
XRUN Count  . . . . . . . . . :    10               42               3         
Delay Count (>spare time) . . :     1                0               0         
Delay Count (>1000 usecs) . . :     0                0               0         
Delay Maximum . . . . . . . . : 307419   usecs    6492   usecs   19339   usecs 
Cycle Maximum . . . . . . . . :   858   usecs      866   usecs     860   usecs 
Average DSP Load. . . . . . . :    37.3 %           14.5 %          37.7 %     
Average CPU System Load . . . :    10.2 %            4.5 %          10.0 %     
Average CPU User Load . . . . :    26.6 %           11.4 %          23.8 %     
Average CPU Nice Load . . . . :     0.0 %            0.0 %           0.0 %     
Average CPU I/O Wait Load . . :     2.0 %            0.7 %           0.2 %     
Average CPU IRQ Load  . . . . :     0.8 %            0.7 %           0.7 %     
Average CPU Soft-IRQ Load . . :     0.0 %            0.0 %           0.0 %     
Average Interrupt Rate  . . . :  1730.3 /sec      1695.5 /sec     1694.8 /sec  
Average Context-Switch Rate . : 11523.1 /sec      6151.1 /sec    11672.2 /sec  
*********************************************


==================================================
With CAP_SYS_NICE, realtime threads are SCHED_FIFO
==================================================

*** Terminated Tue Jan 18 23:41:42 CST 2005 ***
************* SUMMARY RESULT ****************
Total seconds ran . . . . . . :   300
Number of clients . . . . . . :    20
Ports per client  . . . . . . :     4
Frames per buffer . . . . . . :    64
*********************************************
Timeout Count . . . . . . . . :(    0)          (    0)        
XRUN Count  . . . . . . . . . :     0                0         
Delay Count (>spare time) . . :     0                0         
Delay Count (>1000 usecs) . . :     0                0         
Delay Maximum . . . . . . . . :   331   usecs      201   usecs 
Cycle Maximum . . . . . . . . :   882   usecs     1017   usecs 
Average DSP Load. . . . . . . :    40.7 %           41.7 %     
Average CPU System Load . . . :    11.1 %           10.9 %     
Average CPU User Load . . . . :    26.7 %           27.7 %     
Average CPU Nice Load . . . . :     0.0 %            0.0 %     
Average CPU I/O Wait Load . . :     0.6 %            1.0 %     
Average CPU IRQ Load  . . . . :     0.7 %            0.7 %     
Average CPU Soft-IRQ Load . . :     0.0 %            0.0 %     
Average Interrupt Rate  . . . :  1708.0 /sec      1697.1 /sec  
Average Context-Switch Rate . : 13297.0 /sec     13314.8 /sec  
*********************************************

-- 
  joq

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-19  6:54 ` Jack O'Quin
@ 2005-01-19  7:56   ` Con Kolivas
  2005-01-19 14:27     ` Jack O'Quin
  2005-01-19  9:33   ` Con Kolivas
  1 sibling, 1 reply; 18+ messages in thread
From: Con Kolivas @ 2005-01-19  7:56 UTC (permalink / raw)
  To: Jack O'Quin; +Cc: linux, Ingo Molnar, rlrevell, paul, CK Kernel

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

Jack O'Quin wrote:
> Con Kolivas <kernel@kolivas.org> writes:
> 
> 
>>This patch for 2.6.11-rc1 provides a method of providing real time
>>scheduling to unprivileged users which increasingly is desired for
>>multimedia workloads.
> 
> 
> I ran some jack_test3.2 runs with this, using all the default
> settings.  The results of three runs differ quite significantly for no
> obvious reason.  I can't figure out why the DSP load should vary so
> much.  
> 
> These may be bogus results.  It looks like a libjack bug sometimes
> causes clients to crash when deactivating.  I will investigate more
> tomorrow, and come up with a fix.
> 
> For comparison, I also made a couple of runs using the realtime-lsm to
> grant SCHED_FIFO privileges.  There was some variablility, but nowhere
> near as much (and no crashes).  I used schedtool to verify that the
> jackd threads actually have the expected scheduler type.

Thanks for those. If you don't know what to make of the dsp variation 
and the crashing then I'm not sure what I should make of it either. It's 
highly likely that my code still needs fixing to ensure it behaves as 
expected. Already one bug has been picked up in testing with respect to 
yield() so there may be others. By design, if you set iso_cpu to 100 it 
should be as good as SCHED_RR. If not, then the implementation is still 
buggy.

Cheers,
Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-19  6:54 ` Jack O'Quin
  2005-01-19  7:56   ` Con Kolivas
@ 2005-01-19  9:33   ` Con Kolivas
  2005-01-19 17:12     ` Jack O'Quin
  1 sibling, 1 reply; 18+ messages in thread
From: Con Kolivas @ 2005-01-19  9:33 UTC (permalink / raw)
  To: Jack O'Quin; +Cc: linux, Ingo Molnar, rlrevell, paul, CK Kernel

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

Jack O'Quin wrote:
> Con Kolivas <kernel@kolivas.org> writes:
> 
> 
>>This patch for 2.6.11-rc1 provides a method of providing real time
>>scheduling to unprivileged users which increasingly is desired for
>>multimedia workloads.
> 
> 
> I ran some jack_test3.2 runs with this, using all the default
> settings.  The results of three runs differ quite significantly for no
> obvious reason.  I can't figure out why the DSP load should vary so
> much.  

I installed a fresh jack installation and got the test suite. I tried 
running the test suite and found it only ran to completion if I changed 
the run time right down to 30 seconds from 300. Otherwise it bombed out 
almost instantly at the default of 300. I don't know if that helps you 
debug the problem or not but it might be worth mentioning.

As for my own results I gave it a run on the weak SCHED_ISO 
implementation in 2.6.10-ck5 (P4HT 3.06):

SCHED_NORMAL:
*********************************************
Timeout Count . . . . . . . . :(    0)
XRUN Count  . . . . . . . . . :    74
Delay Count (>spare time) . . :     0
Delay Count (>1000 usecs) . . :     0
Delay Maximum . . . . . . . . :     0   usecs
Cycle Maximum . . . . . . . . :  1046   usecs
Average DSP Load. . . . . . . :    18.0 %
Average CPU System Load . . . :     2.5 %
Average CPU User Load . . . . :     7.8 %
Average CPU Nice Load . . . . :     0.1 %
Average CPU I/O Wait Load . . :     0.1 %
Average CPU IRQ Load  . . . . :     0.1 %
Average CPU Soft-IRQ Load . . :     0.0 %
Average Interrupt Rate  . . . :  1776.0 /sec
Average Context-Switch Rate . : 10290.4 /sec
*********************************************

SCHED_NORMAL nice -n -20:
*********************************************
Timeout Count . . . . . . . . :(    0)
XRUN Count  . . . . . . . . . :   266
Delay Count (>spare time) . . :     0
Delay Count (>1000 usecs) . . :     0
Delay Maximum . . . . . . . . :     0   usecs
Cycle Maximum . . . . . . . . :  2239   usecs
Average DSP Load. . . . . . . :    28.6 %
Average CPU System Load . . . :     2.9 %
Average CPU User Load . . . . :    10.2 %
Average CPU Nice Load . . . . :     0.0 %
Average CPU I/O Wait Load . . :     1.0 %
Average CPU IRQ Load  . . . . :     0.2 %
Average CPU Soft-IRQ Load . . :     0.1 %
Average Interrupt Rate  . . . :  2049.7 /sec
Average Context-Switch Rate . : 10145.1 /sec
*********************************************

SCHED_ISO:
*********************************************
Timeout Count . . . . . . . . :(    0)
XRUN Count  . . . . . . . . . :     1
Delay Count (>spare time) . . :     0
Delay Count (>1000 usecs) . . :     0
Delay Maximum . . . . . . . . :     0   usecs
Cycle Maximum . . . . . . . . :   687   usecs
Average DSP Load. . . . . . . :    19.9 %
Average CPU System Load . . . :     2.6 %
Average CPU User Load . . . . :    10.3 %
Average CPU Nice Load . . . . :     0.0 %
Average CPU I/O Wait Load . . :     0.0 %
Average CPU IRQ Load  . . . . :     0.2 %
Average CPU Soft-IRQ Load . . :     0.3 %
Average Interrupt Rate  . . . :  2166.2 /sec
Average Context-Switch Rate . : 10117.3 /sec
*********************************************

SCHED_FIFO:
*********************************************
Timeout Count . . . . . . . . :(    0)
XRUN Count  . . . . . . . . . :     2
Delay Count (>spare time) . . :     0
Delay Count (>1000 usecs) . . :     0
Delay Maximum . . . . . . . . :     0   usecs
Cycle Maximum . . . . . . . . :   544   usecs
Average DSP Load. . . . . . . :    19.5 %
Average CPU System Load . . . :     3.1 %
Average CPU User Load . . . . :    12.6 %
Average CPU Nice Load . . . . :     0.0 %
Average CPU I/O Wait Load . . :     0.0 %
Average CPU IRQ Load  . . . . :     1.0 %
Average CPU Soft-IRQ Load . . :     1.1 %
Average Interrupt Rate  . . . :  5018.4 /sec
Average Context-Switch Rate . : 10902.5 /sec
*********************************************


It occasionally would segfault on client exit as well (as you've already 
mentioned). I think we're still in the dark here to be honest.

Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-19  5:26 ` utz
  2005-01-19  5:31   ` Con Kolivas
@ 2005-01-19 14:01   ` Con Kolivas
  1 sibling, 0 replies; 18+ messages in thread
From: Con Kolivas @ 2005-01-19 14:01 UTC (permalink / raw)
  To: utz; +Cc: LKML, Ingo Molnar, rlrevell, paul, joq, CK Kernel, Andrew Morton

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

Just as a headsup there is a new cleaned up patch here:
http://ck.kolivas.org/patches/SCHED_ISO/2.6.11-rc1-iso-0501192240.diff

The yield bug is still eluding my capture but appears to be related to 
the array switch of yielding and rescheduling as ISO after the fact. 
Still working on it.

Cheers,
Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-19  7:56   ` Con Kolivas
@ 2005-01-19 14:27     ` Jack O'Quin
  0 siblings, 0 replies; 18+ messages in thread
From: Jack O'Quin @ 2005-01-19 14:27 UTC (permalink / raw)
  To: Con Kolivas; +Cc: linux, Ingo Molnar, rlrevell, paul, CK Kernel

Con Kolivas <kernel@kolivas.org> writes:

> Jack O'Quin wrote:
>> Con Kolivas <kernel@kolivas.org> writes:
>>
>>>This patch for 2.6.11-rc1 provides a method of providing real time
>>>scheduling to unprivileged users which increasingly is desired for
>>>multimedia workloads.
>> I ran some jack_test3.2 runs with this, using all the default
>> settings.  The results of three runs differ quite significantly for no
>> obvious reason.  I can't figure out why the DSP load should vary so
>> much.  These may be bogus results.  It looks like a libjack bug
>> sometimes
>> causes clients to crash when deactivating.  I will investigate more
>> tomorrow, and come up with a fix.
>> For comparison, I also made a couple of runs using the realtime-lsm
>> to
>> grant SCHED_FIFO privileges.  There was some variablility, but nowhere
>> near as much (and no crashes).  I used schedtool to verify that the
>> jackd threads actually have the expected scheduler type.
>
> Thanks for those. If you don't know what to make of the dsp variation
> and the crashing then I'm not sure what I should make of it
> either. It's highly likely that my code still needs fixing to ensure
> it behaves as expected. Already one bug has been picked up in testing
> with respect to yield() so there may be others. By design, if you set
> iso_cpu to 100 it should be as good as SCHED_RR. If not, then the
> implementation is still buggy.

I fixed that bug in libjack, eliminating the crashes on disconnect.

They must have been perturbing the numbers quite a bit.  Here are
three more runs (all SCHED_ISO).  The results are much more
consistent.  The only significant anomaly I see now is that small
Delay Max in the first run.

*** Terminated Wed Jan 19 01:04:55 CST 2005 ***
************* SUMMARY RESULT ****************
Total seconds ran . . . . . . :   300
Number of clients . . . . . . :    20
Ports per client  . . . . . . :     4
Frames per buffer . . . . . . :    64
*********************************************
Timeout Count . . . . . . . . :(    1)          (    5)         (    3)         
XRUN Count  . . . . . . . . . :     2               16              15          
Delay Count (>spare time) . . :     0                0               0          
Delay Count (>1000 usecs) . . :     0                0               0          
Delay Maximum . . . . . . . . : 11932   usecs    101053  usecs   98719   usecs  
Cycle Maximum . . . . . . . . :   868   usecs     1099   usecs     887   usecs  
Average DSP Load. . . . . . . :    37.9 %           33.6 %          36.0 %      
Average CPU System Load . . . :    10.2 %            9.0 %           9.9 %      
Average CPU User Load . . . . :    24.5 %           22.7 %          23.0 %      
Average CPU Nice Load . . . . :     0.0 %            0.0 %           0.0 %      
Average CPU I/O Wait Load . . :     0.6 %            3.4 %           0.4 %      
Average CPU IRQ Load  . . . . :     0.7 %            0.7 %           0.7 %      
Average CPU Soft-IRQ Load . . :     0.0 %            0.0 %           0.0 %      
Average Interrupt Rate  . . . :  1688.1 /sec      1696.1 /sec     1685.2 /sec   
Average Context-Switch Rate . : 11727.9 /sec     10642.4 /sec    11568.3 /sec
*********************************************

I should probably experiment with higher thresholds on the SCHED_ISO class.
-- 
  joq

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-19  9:33   ` Con Kolivas
@ 2005-01-19 17:12     ` Jack O'Quin
  2005-01-20  0:07       ` Con Kolivas
  0 siblings, 1 reply; 18+ messages in thread
From: Jack O'Quin @ 2005-01-19 17:12 UTC (permalink / raw)
  To: Con Kolivas
  Cc: linux, Ingo Molnar, rlrevell, paul, CK Kernel, Rui Nuno Capela

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


[including Rui Nuno Capela in cc: list]

>> Con Kolivas <kernel@kolivas.org> writes:
>>
>>>This patch for 2.6.11-rc1 provides a method of providing real time
>>>scheduling to unprivileged users which increasingly is desired for
>>>multimedia workloads.

> Jack O'Quin wrote:
>> I ran some jack_test3.2 runs with this, using all the default
>> settings.  The results of three runs differ quite significantly for no
>> obvious reason.  I can't figure out why the DSP load should vary so
>> much.

Con Kolivas <kernel@kolivas.org> writes:
> I installed a fresh jack installation and got the test suite. I tried
> running the test suite and found it only ran to completion if I
> changed the run time right down to 30 seconds from 300. Otherwise it
> bombed out almost instantly at the default of 300. I don't know if
> that helps you debug the problem or not but it might be worth
> mentioning.

Here are a couple of bug fixes for the test package.  I still had not
gotten them to Rui (the test author).  He has created several newer
versions, but I'm still using this modified jack_test3.2, so the
number comparisons will continue to make sense.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: joq mods to jack_test3.2 --]
[-- Type: text/x-patch, Size: 5454 bytes --]

--- jack_test3.2/jack_test3_client.cpp	Thu Dec  9 10:26:12 2004
+++ jack_test/jack_test3_client.cpp	Sat Jan 15 20:48:20 2005
@@ -13,20 +13,25 @@
 unsigned int seconds_to_run = 60;
 unsigned int num_of_ports   = 4;
 
+/* mix all the input ports to each output port */
 int process(jack_nframes_t frames, void *arg) 
 {
 	// std::cout << "process callback" << std::endl;
 	jack_default_audio_sample_t *ibuf;
 	jack_default_audio_sample_t *obuf;
 	for (int i = 0; i < num_of_ports; i++) {
-		obuf = (jack_default_audio_sample_t*) jack_port_get_buffer(oports[i], frames);
+		obuf = (jack_default_audio_sample_t*)
+			jack_port_get_buffer(oports[i], frames);
 		for (int j = 0; j < num_of_ports; j++) {
-			ibuf = (jack_default_audio_sample_t*) jack_port_get_buffer(iports[j], frames);
-			for (jack_nframes_t frame = 0; frame < frames; frame++) {
+			ibuf = (jack_default_audio_sample_t*)
+				jack_port_get_buffer(iports[j], frames);
+			for (jack_nframes_t frame = 0;
+			     frame < frames; frame++) {
 				if (j == 0)
 					obuf[frame] = 0.0; 
 				if (ibuf[frame] < -1E-6 || ibuf[frame] > +1E-6)
-					obuf[frame] += ibuf[frame] / (float) num_of_ports;
+					obuf[frame] += ibuf[frame]
+						/ (float) num_of_ports;
 			}
 		}
 	}
@@ -68,10 +73,23 @@
 	for (int i = 0; i < num_of_ports; i++) {
 		std::stringstream iport_name;
 		iport_name << "in_" << i;
-		iports[i] = jack_port_register(client,  iport_name.str().c_str(), JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput|JackPortIsTerminal, 0);
+		iports[i] =
+			jack_port_register(client,
+					   iport_name.str().c_str(),
+					   JACK_DEFAULT_AUDIO_TYPE,
+					   JackPortIsInput|JackPortIsTerminal,
+					   0);
 		std::stringstream oport_name;
 		oport_name << "out_" << i;
-		oports[i] = jack_port_register(client, oport_name.str().c_str(), JACK_DEFAULT_AUDIO_TYPE, JackPortIsTerminal|JackPortIsOutput, 0);
+		oports[i] = jack_port_register(client,
+					       oport_name.str().c_str(),
+					       JACK_DEFAULT_AUDIO_TYPE,
+					       JackPortIsTerminal|JackPortIsOutput,
+					       0);
+		if ((iports[i] == NULL) || (oports[i] == NULL)) {
+			std::cout << "port registration failed" << std::endl;
+			goto exit;
+		}
 	}
 	std::cout << "set_process_callback" << std::endl;
 	jack_set_process_callback(client, process, 0);
@@ -85,6 +103,8 @@
 	sleep(seconds_to_run);
 
 	jack_deactivate(client);
+
+exit:
 	jack_client_close(client);
 	
 	delete [] iports;
--- jack_test3.2/jack_test3_nmeter.c	Sat Nov 27 09:08:01 2004
+++ jack_test/jack_test3_nmeter.c	Thu Dec 30 07:50:38 2004
@@ -21,7 +21,9 @@
 //==============
 #define NL "\n"
 typedef unsigned long long ullong;
+#ifndef __USE_MISC
 typedef unsigned long ulong;
+#endif
 
 typedef ulong sample_t;
 
--- jack_test3.2/jack_test3_run.sh	Fri Dec 10 06:21:21 2004
+++ jack_test/jack_test3_run.sh	Sat Jan 15 22:23:06 2005
@@ -6,12 +6,14 @@
 CLIENTS=$2
 PORTS=$3
 PERIOD=$4
+PLYBK_PORTS=$5
 
 # Parameter defaults.
 [ -z "${SECS}"    ] && SECS=300
 [ -z "${CLIENTS}" ] && CLIENTS=20
 [ -z "${PORTS}"   ] && PORTS=4
 [ -z "${PERIOD}"  ] && PERIOD=64
+[ -z "${PLYBK_PORTS}"  ] && PLYBK_PORTS=32
 
 # Local tools must be on same directory...
 BASEDIR=`dirname $0`
@@ -24,13 +26,13 @@
 NMETER_ARGS="t c i x b m"
 
 # jackd configuration.
-JACKD="/usr/bin/jackd"
+JACKD="jackd"
 JACKD_DRIVER="alsa"
 JACKD_DEVICE="hw:0"
 JACKD_PRIO=60
 JACKD_RATE=44100
-JACKD_PORTS=$(((${CLIENTS} + 1) * ${PORTS} * 2))
-JACKD_ARGS="-v -R -P${JACKD_PRIO} -p${JACKD_PORTS} -d${JACKD_DRIVER} -d${JACKD_DEVICE} -r${JACKD_RATE} -p${PERIOD} -n2 -S -P"
+JACKD_PORTS=$((${CLIENTS} * ${PORTS} * 2 + ${PLYBK_PORTS}))
+JACKD_ARGS="-Rv -p${JACKD_PORTS} -d${JACKD_DRIVER} -d${JACKD_DEVICE} -r${JACKD_RATE} -p${PERIOD} -n2 -P"
 
 # client test configuration.
 CLIENT="${BASEDIR}/jack_test3_client"
@@ -85,6 +87,7 @@
 echo "Number of clients  (CLIENTS) = ${CLIENTS}"	>> ${LOG} 2>&1
 echo "Ports per client     (PORTS) = ${PORTS}"		>> ${LOG} 2>&1
 echo "Frames per buffer   (PERIOD) = ${PERIOD}"		>> ${LOG} 2>&1
+echo "Playback ports (PLYBK_PORTS) = ${PLYBK_PORTS}"	>> ${LOG} 2>&1
 echo >> ${LOG} 2>&1
 
 exec_log "uname -a"
@@ -102,7 +105,7 @@
 ilist_log 
 
 #
-# Lauch nmeter in the background...
+# Launch nmeter in the background...
 #
 echo -n "Launching `basename ${NMETER}`..."
 (${NMETER} ${NMETER_ARGS} >> ${LOG} 2>&1) &
@@ -110,7 +113,7 @@
 echo "done."
 sleep 1
 
-# Lauch the test client suite...
+# Launch the test client suite...
 SLEEP=6
 echo -n "Launching ${CLIENTS} ${CLIENT}(s) instance(s)..."
 for NUM in `seq 1 ${CLIENTS}`; do
@@ -129,7 +132,7 @@
 (sleep ${SLEEP}; killall `basename ${JACKD}`) &
 
 #
-# Lauch jackd and wait for it...
+# Launch jackd and wait for it...
 #
 echo -n "Running `basename ${JACKD}`..."
 exec_log ${JACKD} ${JACKD_ARGS}
@@ -149,7 +152,7 @@
 sleep 1
 sync
 
-# Summary log analynis...
+# Summary log analysis...
 cat ${LOG} | awk -f ${BASEDIR}/jack_test3_summary.awk | tee -a ${LOG}
 
 # Finally, plot log output...
--- jack_test3.2/Makefile	Thu Nov 25 05:28:47 2004
+++ jack_test/Makefile	Sat Jan 15 20:50:04 2005
@@ -1,10 +1,10 @@
 all:	jack_test3_nmeter jack_test3_client
 
 jack_test3_nmeter:	jack_test3_nmeter.c
-	gcc -o jack_test3_nmeter jack_test3_nmeter.c
+	$(CC) -g -o jack_test3_nmeter jack_test3_nmeter.c
 
 jack_test3_client:	jack_test3_client.cpp
-	g++ -o jack_test3_client jack_test3_client.cpp -ljack
+	$(CXX) -g -o jack_test3_client jack_test3_client.cpp -ljack
 
 clean:
 	rm -vf jack_test3_nmeter jack_test3_client

[-- Attachment #3: Type: text/plain, Size: 100 bytes --]


For completeness, here's Rui's unmodified test package against which
these diff's were generated.


[-- Attachment #4: JACK test version 3.2 (from rncbc) --]
[-- Type: archive/tar, Size: 11383 bytes --]

[-- Attachment #5: Type: text/plain, Size: 359 bytes --]


There's also a modified script for running with nice --20, called
jack_test3_nice.sh.  I hacked it for Ingo's tests.  It really should
be integrated into the main jack_test3_run.sh as an option, but I have
not bothered.  I think we're beyond that at this point, anyway.
Mainly, it proves that per-thread granularity is essential for making
this stuff work.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: hacked up jack_test3_run.sh for running with nice --20 --]
[-- Type: text/x-sh, Size: 3794 bytes --]

#!/bin/sh
#

# Command line arguments.
SECS=$1
CLIENTS=$2
PORTS=$3
PERIOD=$4
PLYBK_PORTS=$5

# Parameter defaults.
[ -z "${SECS}"    ] && SECS=300
[ -z "${CLIENTS}" ] && CLIENTS=20
[ -z "${PORTS}"   ] && PORTS=4
[ -z "${PERIOD}"  ] && PERIOD=64
[ -z "${PLYBK_PORTS}"  ] && PLYBK_PORTS=32

# Local tools must be on same directory...
BASEDIR=`dirname $0`

# Make sure our local tools are in place.
(cd ${BASEDIR}; make all > /dev/null) || exit 1

# nmeter configuration.
NMETER="${BASEDIR}/jack_test3_nmeter"
NMETER_ARGS="t c i x b m"

# jackd configuration.
JACKD="jackd"
JACKD_DRIVER="alsa"
JACKD_DEVICE="hw:0"
JACKD_PRIO=60
JACKD_RATE=44100
JACKD_PORTS=$((${CLIENTS} * ${PORTS} * 2 + ${PLYBK_PORTS}))
JACKD_ARGS="-v -p${JACKD_PORTS} -d${JACKD_DRIVER} -d${JACKD_DEVICE} -r${JACKD_RATE} -p${PERIOD} -n2 -P"

# client test configuration.
CLIENT="${BASEDIR}/jack_test3_client"
CLIENT_ARGS="${SECS} ${PORTS}"

# process/thread list configuration.
PIDOF="/sbin/pidof"
PLIST="ps -o pid,tid,class,rtprio,ni,pri,pcpu,stat,comm"

# Log filename.
LOG="jack_test3-`uname -r`-`date +'%Y%m%d%H%M'`.log"

# Command executive and logger.
exec_log ()
{
	CMD="$*"
	echo "-----------------------"		>> ${LOG} 2>&1
	echo "# ${CMD}"				>> ${LOG} 2>&1
	${CMD}					>> ${LOG} 2>&1
	echo					>> ${LOG} 2>&1
}

# Process/thread status loggers.
plist_log ()
{
	PIDS="$*"
	if [ -n "${PIDS}" ]; then
		echo "- - - - - - - - - - - -"	>> ${LOG} 2>&1
		${PLIST} -m ${PIDS}		>> ${LOG} 2>&1
		echo				>> ${LOG} 2>&1
	fi
}


# IRQ thread status loggers.
ilist_log ()
{
	echo "- - - - - - - - - - - -"	>> ${LOG} 2>&1
	${PLIST} --sort -rtprio -e \
	| egrep '(^[ ]+PID|IRQ|jack)'	>> ${LOG} 2>&1
	echo				>> ${LOG} 2>&1
}


#
# Log headings -- show some relevant info...
#
echo "*** Started `date` ***" >> ${LOG} 2>&1

echo >> ${LOG} 2>&1
echo "Seconds to run        (SECS) = ${SECS}"		>> ${LOG} 2>&1
echo "Number of clients  (CLIENTS) = ${CLIENTS}"	>> ${LOG} 2>&1
echo "Ports per client     (PORTS) = ${PORTS}"		>> ${LOG} 2>&1
echo "Frames per buffer   (PERIOD) = ${PERIOD}"		>> ${LOG} 2>&1
echo "Playback ports (PLYBK_PORTS) = ${PLYBK_PORTS}"	>> ${LOG} 2>&1
echo >> ${LOG} 2>&1

exec_log "uname -a"

exec_log "cat /proc/asound/version"
exec_log "cat /proc/asound/cards"

#exec_log "grep . /proc/sys/kernel/*_preemption"
#exec_log "grep . /proc/irq/*/*/threaded"
#exec_log "grep . /sys/block/hd*/queue/max_sectors_kb"

exec_log "cat /proc/interrupts"

# This is just about to be sure...
ilist_log 

#
# Launch nmeter in the background...
#
echo -n "Launching `basename ${NMETER}`..."
(nice -15 ${NMETER} ${NMETER_ARGS} >> ${LOG} 2>&1) &
sleep 2
echo "done."
sleep 1

# Launch the test client suite...
SLEEP=6
echo -n "Launching ${CLIENTS} ${CLIENT}(s) instance(s)..."
for NUM in `seq 1 ${CLIENTS}`; do
	CLIENT_CMDLINE="${CLIENT} ${CLIENT_ARGS}"
	SLEEP=$((${SLEEP} + 3))
	(sleep ${SLEEP}; echo -n "$NUM..."; exec_log ${CLIENT_CMDLINE}) &
done
echo "done."

# Let there be some evidence of process status...
SLEEP=$((${SLEEP} + 6))
(sleep ${SLEEP}; plist_log -C `basename ${JACKD}`; plist_log -C `basename ${CLIENT}`) &

# Let jackd live for extended but limited time...
SLEEP=$((${SLEEP} + ${SECS}))
(sleep ${SLEEP}; killall `basename ${JACKD}`) &

#
# Launch jackd and wait for it...
#
echo -n "Running `basename ${JACKD}`..."
exec_log ${JACKD} ${JACKD_ARGS}
echo "done."
sleep 1

#echo -n "Killing `basename ${CLIENT}`..."
#killall `basename ${CLIENT}` && echo "OK." || echo "FAILED."
#sleep 1

echo -n "Killing `basename ${NMETER}`..."
killall `basename ${NMETER}` && echo "OK." || echo "FAILED."

echo "*** Terminated `date` ***" >> ${LOG} 2>&1

sync
sleep 1
sync

# Summary log analynis...
cat ${LOG} | awk -f ${BASEDIR}/jack_test3_summary.awk | tee -a ${LOG}

# Finally, plot log output...
${BASEDIR}/jack_test3_plot.sh ${LOG}

[-- Attachment #7: Type: text/plain, Size: 1433 bytes --]


What version of JACK do you have?  (jackd --version)

You need a recent CVS version to get all the data collection Rui and
Lee have added.  Looks like you're missing that.  Delay Max is an
important statistic.

You need a *very* recent version (about 10 minutes ago) to fix that
jack_deactivate() segfault.  (see URL below)

> It occasionally would segfault on client exit as well (as you've
> already mentioned). I think we're still in the dark here to be honest.

Try again with JACK 0.99.48.  It's in CVS now, but you probably need
this tarball to get around the dreaded SourceForge anon CVS lag...

   http://www.joq.us/jack/tarballs/jack-audio-connection-kit-0.99.48.tar.gz

The results I get with these versions are a lot more stable.  But,
there are still some puzzles about the scheduling.  Do you distinguish
different SCHED_ISO priorities?  

JACK runs with three different SCHED_FIFO priorities:

  (1) The main jackd audio thread uses the -P parameter.  The JACK
  default is 10, but Rui's script sets it with -P60.  I don't think
  the absolute value matters, but the value relative to the other JACK
  realtime threads probably does.

  (2) The clients' process threads run at a priority one less (59).

  (3) The watchdog timer thread runs at a priority 10 greater (70).

  (4) LinuxThreads creates a manager thread in each process running
  one level higher than the highest user realtime thread priority.
-- 
  joq

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-19 17:12     ` Jack O'Quin
@ 2005-01-20  0:07       ` Con Kolivas
  2005-01-20  1:21         ` Jack O'Quin
  0 siblings, 1 reply; 18+ messages in thread
From: Con Kolivas @ 2005-01-20  0:07 UTC (permalink / raw)
  To: Jack O'Quin
  Cc: linux, Ingo Molnar, rlrevell, paul, CK Kernel, Rui Nuno Capela

Jack O'Quin wrote:
> Try again with JACK 0.99.48.  It's in CVS now, but you probably need
> this tarball to get around the dreaded SourceForge anon CVS lag...
> 
>    http://www.joq.us/jack/tarballs/jack-audio-connection-kit-0.99.48.tar.gz

Thanks it finally ran to completion. By the way the patch you sent with 
the test suite did not apply so I had to do it manually (booraroom..)

> The results I get with these versions are a lot more stable.  But,
> there are still some puzzles about the scheduling.  Do you distinguish
> different SCHED_ISO priorities?  

It was not clear whether that would be required or not. This is why 
testing is so critical because if you are having latency issues it 
wouldn't be a problem of getting cpu time since your cpu usage is well 
below the 70% limit.

> 
> JACK runs with three different SCHED_FIFO priorities:
> 
>   (1) The main jackd audio thread uses the -P parameter.  The JACK
>   default is 10, but Rui's script sets it with -P60.  I don't think
>   the absolute value matters, but the value relative to the other JACK
>   realtime threads probably does.
> 
>   (2) The clients' process threads run at a priority one less (59).
> 
>   (3) The watchdog timer thread runs at a priority 10 greater (70).
> 
>   (4) LinuxThreads creates a manager thread in each process running
>   one level higher than the highest user realtime thread priority.

Since I (finally) have it running at this end at last I'll do some 
benchmarking of my own to see how (lack of) priorities affects 
SCHED_ISO. If it is inadequate, it wont be too difficult to add them to 
the design. The problem with priorities is that once you go over the cpu 
limit everyone suffers equally; but that's a failsafe that you shouldn't 
actually hit in normal usage so it probably doesn't matter... Hmm come 
to think of it, it probably _is_ a good idea to implement priority 
support afterall.

Cheers,
Con

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling
  2005-01-20  0:07       ` Con Kolivas
@ 2005-01-20  1:21         ` Jack O'Quin
  0 siblings, 0 replies; 18+ messages in thread
From: Jack O'Quin @ 2005-01-20  1:21 UTC (permalink / raw)
  To: Con Kolivas
  Cc: linux, Ingo Molnar, rlrevell, paul, CK Kernel, Rui Nuno Capela

Con Kolivas <kernel@kolivas.org> writes:

> Jack O'Quin wrote:
>> Try again with JACK 0.99.48.  It's in CVS now, but you probably need
>> this tarball to get around the dreaded SourceForge anon CVS lag...
>>
>> http://www.joq.us/jack/tarballs/jack-audio-connection-kit-0.99.48.tar.gz
>
> Thanks it finally ran to completion. By the way the patch you sent
> with the test suite did not apply so I had to do it manually
> (booraroom..)

Oops!  Sorry.  I generated those by hand using some rather crude 
`diff -u .... >> xxx.diff' commands.  

We should just add Rui's latest version to JACK CVS.

> Since I (finally) have it running at this end at last I'll do some
> benchmarking of my own to see how (lack of) priorities affects
> SCHED_ISO. If it is inadequate, it wont be too difficult to add them
> to the design. The problem with priorities is that once you go over
> the cpu limit everyone suffers equally; but that's a failsafe that you
> shouldn't actually hit in normal usage so it probably doesn't
> matter... 

I'd be surprised if we're hitting it in this test.  AFAICT, our
"Average DSP Load" should approximate your CPU limit.  That's running
in the 30% to 40% range.  Is there any way to verify this?  Is your
running average readable in /proc/sys/kernel somewhere?

We do need to test that the system degrades gracefully when the CPU is
overloaded.  That *will* happen (the dreaded P4 float denormal
problems quickly come to mind).  At some point, the user should be
allowed to choose how much CPU to consume, possibly shutting down
plugins as needed.

> Hmm come to think of it, it probably _is_ a good idea to implement
> priority support afterall.

Hard to say for sure without trying it.  These threads are dealing
with a realtime cycle that is smaller than normal scheduler time
slices.  Getting all the work done is important.  But, getting it done
in the right order might make a difference for important statistics
like Max Delay.
-- 
  joq

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2005-01-20  1:19 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-18 13:01 [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling Con Kolivas
2005-01-18 14:53 ` Con Kolivas
2005-01-18 15:45 ` [ck] " Cal
2005-01-18 15:53   ` Con Kolivas
2005-01-18 16:23     ` Jack O'Quin
2005-01-18 16:17   ` Jack O'Quin
2005-01-19  2:02     ` Lee Revell
2005-01-19  2:08       ` Con Kolivas
2005-01-19  5:26 ` utz
2005-01-19  5:31   ` Con Kolivas
2005-01-19 14:01   ` Con Kolivas
2005-01-19  6:54 ` Jack O'Quin
2005-01-19  7:56   ` Con Kolivas
2005-01-19 14:27     ` Jack O'Quin
2005-01-19  9:33   ` Con Kolivas
2005-01-19 17:12     ` Jack O'Quin
2005-01-20  0:07       ` Con Kolivas
2005-01-20  1:21         ` Jack O'Quin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).