lkml.org 
[lkml]   [2002]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[sched] [patch] interactiveness-improvements-2.5.3-pre2-A0

the attached patch cleans up and improves the interactiveness code in
2.5.3-pre2 further. It's the interactiveness code from -J2 that got good
interactiveness feedback.

the patch changes three aspects of interactiveness:

1) the bonus/penalty of SCHED_OTHER tasks has been reduced by 10%, from
[-20 ... +20] to [ -18 ... +19 ]. The reason is two-fold:

- protect nice -20 interactive tasks from default-nicelevel
interactive tasks. This improves audio playback quality, making
nice -20 a more protected priority domain.

- protect default-nicelevel CPU hogs from nice +19 CPU hogs. This
means that nice +19 SETI jobs will not distrupt the timeslices
of normal kernel compilation jobs.

2) improve the definition of TASK_INTERACTIVE:

- the bottom 25% of the priority range is for 'unconditionally
interactive tasks'.

- the top 25% of the priority range is for 'unconditionally CPU-hog
tasks'

- the middle 50% is for 'conditionally interactive' tasks.
Interactivity depends on whether a task has 'won' at least 3
priority levels due to being interactive, relative to its default
priority level.

this change has the following effect: tasks with negative nice values it's
easier to be interactive, and harder to become rated as CPU hogs. For
tasks with positive nice values it's much harder to become rated as
interactive, and easy to be rated as CPU hogs. Tasks on the default
nice-level have none of the 'prejudice' ratings, it depends on its actual
bonus whether it's rated as interactive or not.

3) newly forked children lose 20% of their parent's priority and sleep
average.

this change has a positive effect on starting xterms during high-load
situations. The process that starts the xterm is usually a heavily
interactive task. But the first xterm process often fork()s a second
process, which was penalized too heavily in the previous fork_wakeup code,
causing that process to get into the 'CPU-bound hell', causing massive
delays of xterm startups. This rule is a purely experimental value, but it
expresses the basic concept correctly as well: we want children to get
some of the benefits of their parents, but we also want them to not get
*all* of the benefits, and work to achieve their own bonuses.

Ingo
--- linux/kernel/sched.c.orig Sun Jan 20 11:39:41 2002
+++ linux/kernel/sched.c Sun Jan 20 11:39:57 2002
@@ -95,21 +95,26 @@
}

/*
- * A task is 'heavily interactive' if it has reached the
- * bottom 25% of the SCHED_OTHER priority range - in this
+ * A task is 'heavily interactive' if it either has reached the
+ * bottom 25% of the SCHED_OTHER priority range, or if it is below
+ * its default priority by at least 3 priority levels. In this
* case we favor it by reinserting it on the active array,
* even after it expired its current timeslice.
*
+ * A task is a 'CPU hog' if it's either in the upper 25% of the
+ * SCHED_OTHER priority range, or if's not an interactive task.
+ *
* A task can get a priority bonus by being 'somewhat
* interactive' - and it will get a priority penalty for
* being a CPU hog.
*
- * CPU-hog penalties cannot go more than 5 above the default
- * priority level. Priority bonus cannot go below the minimum
- * priority level.
*/
-#define PRIO_INTERACTIVE (MAX_RT_PRIO + MAX_USER_PRIO/3)
-#define TASK_INTERACTIVE(p) ((p)->prio <= PRIO_INTERACTIVE)
+#define PRIO_INTERACTIVE (MAX_RT_PRIO + MAX_USER_PRIO/4)
+#define PRIO_CPU_HOG (MAX_RT_PRIO + MAX_USER_PRIO*3/4)
+
+#define TASK_INTERACTIVE(p) (((p)->prio <= PRIO_INTERACTIVE) || \
+ (((p)->prio < PRIO_CPU_HOG) && \
+ ((p)->prio <= NICE_TO_PRIO((p)->__nice)-3)))

static inline int effective_prio(task_t *p)
{
@@ -117,9 +122,18 @@

/*
* Here we scale the actual sleep average [0 .... MAX_SLEEP_AVG]
- * into the 20 ... -20 bonus/penalty range.
+ * into the 19 ... -18 bonus/penalty range.
+ *
+ * We take off the 10% from the full 0...39 priority range so that:
+ *
+ * 1) nice +19 CPU hogs do not preempt nice 0 CPU hogs just yet.
+ * 2) nice -20 interactive tasks do not get preempted by
+ * nice 0 interactive tasks.
+ *
+ * Both properties are important to certain applications.
*/
- bonus = MAX_USER_PRIO * p->sleep_avg / MAX_SLEEP_AVG - MAX_USER_PRIO/2;
+ bonus = MAX_USER_PRIO*9/10 * p->sleep_avg / MAX_SLEEP_AVG -
+ MAX_USER_PRIO*9/10/2;
prio = NICE_TO_PRIO(p->__nice) - bonus;
if (prio < MAX_RT_PRIO)
prio = MAX_RT_PRIO;
@@ -261,9 +275,8 @@

p->state = TASK_RUNNING;
if (!rt_task(p)) {
- p->prio += MAX_USER_PRIO/10;
- if (p->prio > MAX_PRIO-1)
- p->prio = MAX_PRIO-1;
+ p->sleep_avg = (p->sleep_avg * 4) / 5;
+ p->prio = effective_prio(p);
}
spin_lock_irq(&rq->lock);
activate_task(p, rq);
\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.026 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site