linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: [sched] [patch] interactiveness-improvements-2.5.3-pre2-A0
Date: Sun, 20 Jan 2002 14:51:41 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.33.0201201438230.7972-200000@localhost.localdomain> (raw)

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2351 bytes --]


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

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2535 bytes --]

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

                 reply	other threads:[~2002-01-20 11:54 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=Pine.LNX.4.33.0201201438230.7972-200000@localhost.localdomain \
    --to=mingo@elte.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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 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).