mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Guillaume Chazarain <gfc@altern.org>
To: linux-kernel@vger.kernel.org
Subject: [PATCH] Interactivity bits
Date: Tue, 08 Jul 2003 22:12:31 +0200	[thread overview]
Message-ID: <JFNL84UTSKFOJFDFD9D8GBF2WICKG.3f0b25af@monpc> (raw)

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

Hello,

Currently the interactive points a process can have are in a [-5, 5] range,
that is, 25% of the [0, 39] range. Two reasons are mentionned:

1) nice +19 interactive tasks do not preempt nice 0 CPU hogs.
2) nice -20 CPU hogs do not get preempted by nice 0 tasks.

But, using 50% of the range, instead of 25% the interactivity points are better
spread and both rules are still respected.  Having a larger range for
interactivity points it's easier to choose between two interactive tasks.

So, why not changing PRIO_BONUS_RATIO to 50 instead of 25?
Actually it should be in the [45, 49] range to maximize the bonus points
range and satisfy both rules due to integer arithmetic.

Something like that:

--- linux-2.5.74-mm2-O3/kernel/sched.c  2003-07-07 18:46:29.000000000 +0200
+++ linux-2.5.74-mm2-O3/kernel/sched.c-bonus    2003-07-08 15:27:12.000000000 +0200
@@ -71,7 +71,7 @@
 #define CHILD_PENALTY		80
 #define PARENT_PENALTY		100
 #define EXIT_WEIGHT		3
-#define PRIO_BONUS_RATIO	25
+#define PRIO_BONUS_RATIO	45
 #define INTERACTIVE_DELTA	2
 #define MIN_SLEEP_AVG		(HZ)
 #define MAX_SLEEP_AVG		(10*HZ)
@@ -90,13 +90,13 @@
  * We scale it linearly, offset by the INTERACTIVE_DELTA delta.
  * Here are a few examples of different nice levels:
  *
- *  TASK_INTERACTIVE(-20): [1,1,1,1,1,1,1,1,1,0,0]
- *  TASK_INTERACTIVE(-10): [1,1,1,1,1,1,1,0,0,0,0]
- *  TASK_INTERACTIVE(  0): [1,1,1,1,0,0,0,0,0,0,0]
- *  TASK_INTERACTIVE( 10): [1,1,0,0,0,0,0,0,0,0,0]
- *  TASK_INTERACTIVE( 19): [0,0,0,0,0,0,0,0,0,0,0]
+ *  TASK_INTERACTIVE(-20): [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0]
+ *  TASK_INTERACTIVE(-10): [1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0]
+ *  TASK_INTERACTIVE(  0): [1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0]
+ *  TASK_INTERACTIVE( 10): [1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
+ *  TASK_INTERACTIVE( 19): [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  *
- * (the X axis represents the possible -5 ... 0 ... +5 dynamic
+ * (the X axis represents the possible -9 ... 0 ... +9 dynamic
  *  priority range a task can explore, a value of '1' means the
  *  task is rated interactive.)
  *
@@ -325,9 +325,9 @@
  * priority but is modified by bonuses/penalties.
  *
  * We scale the actual sleep average [0 .... MAX_SLEEP_AVG]
- * into the -5 ... 0 ... +5 bonus/penalty range.
+ * into the -9 ... 0 ... +9 bonus/penalty range.
  *
- * We use 25% of the full 0...39 priority range so that:
+ * We use 50% of the full 0...39 priority range so that:
  *
  * 1) nice +19 interactive tasks do not preempt nice 0 CPU hogs.
  * 2) nice -20 CPU hogs do not get preempted by nice 0 tasks.



And if you want to try other values for PRIO_BONUS_RATIO, I attached a simple
hack to generate the infos in the above comment.



Another thing that I was wondering is: should every absence on the runqueue be
considered interactive bonus?  For example, TASK_UNINTERRIBLE tasks receive
bonus when they wake up.  This implies that when a CPU hog becomes a memory hog
and starts swapping, it is considered interactive.  OTOH when a task is swapping
I would like it to consume its data the earliest possible, to avoid losing the
swapping benefit.
So I'd like to know if the patch below is a good or bad thing.

--- linux-2.5.74-mm2-O3/kernel/sched.c  2003-07-07 18:46:29.000000000 +0200
+++ linux-2.5.74-mm2-O3/kernel/sched.c-INTERR   2003-07-08 17:43:59.000000000 +0200
@@ -388,7 +388,7 @@ static inline void activate_task(task_t 
 {
	long sleep_time = jiffies - p->last_run - 1;
 
-	if (sleep_time > 0) {
+	if (sleep_time > 0 && p->state == TASK_INTERRUPTIBLE) {
		unsigned long runtime = jiffies - p->avg_start;
 
		/*




Thanks for your wisdom.
Guillaume


[-- Attachment #2: testbonus.c --]
[-- Type: application/octet-stream, Size: 1982 bytes --]

#include <stdio.h>

/* sched.h */
#define MAX_USER_RT_PRIO        100
#define MAX_RT_PRIO             MAX_USER_RT_PRIO
#define MAX_PRIO                (MAX_RT_PRIO + 40)

/* sched.c */
#define NICE_TO_PRIO(nice)      (MAX_RT_PRIO + (nice) + 20)
#define PRIO_TO_NICE(prio)      ((prio) - MAX_RT_PRIO - 20)
#define TASK_NICE(p)            PRIO_TO_NICE((p)->static_prio)

#define USER_PRIO(p)            ((p)-MAX_RT_PRIO)
#define MAX_USER_PRIO           (USER_PRIO(MAX_PRIO))

#define PRIO_BONUS_RATIO        45      /* Between 45 and 49 */
#define INTERACTIVE_DELTA       2

#define SCALE(v1,v1_max,v2_max) \
        (v1) * (v2_max) / (v1_max)

#define DELTA(p) \
        (SCALE(TASK_NICE(p), 40, MAX_USER_PRIO*PRIO_BONUS_RATIO/100) + \
                INTERACTIVE_DELTA)

#define TASK_INTERACTIVE(p) \
        ((p)->prio <= (p)->static_prio - DELTA(p))

/*****************/

#define MAX_BONUS (MAX_USER_PRIO * PRIO_BONUS_RATIO / 100 / 2)
#define MIN_BONUS (-MAX_BONUS)

typedef struct {
    int static_prio;
    int prio;
} mini_task_t;

static void write_values(int nice)
{
    int bonus;
    mini_task_t p;

    p.static_prio = NICE_TO_PRIO(nice);
    p.prio = p.static_prio + MIN_BONUS;

    printf("TASK_INTERACTIVE(%3d): [%d", nice, TASK_INTERACTIVE(&p));

    for (bonus = MIN_BONUS + 1; bonus <= MAX_BONUS; bonus++) {
        p.prio = p.static_prio + bonus;
        printf(",%d", TASK_INTERACTIVE(&p));
    }

    puts("]");
}

int main(void)
{
    printf("Interactivity bonus between %d and %d\n\n", MIN_BONUS, MAX_BONUS);

    write_values(-20);
    write_values(-10);
    write_values(0);
    write_values(10);
    write_values(19);

    puts("");
    printf("nice +19 interactive tasks : %d\n", NICE_TO_PRIO(19) - MAX_BONUS);
    printf("nice 0 CPU hogs : %d\n", NICE_TO_PRIO(0) - MIN_BONUS);

    puts("");
    printf("nice -20 CPU hogs : %d\n", NICE_TO_PRIO(-20) - MIN_BONUS);
    printf("nice 0 interactive tasks : %d\n", NICE_TO_PRIO(0) - MAX_BONUS);

    return 0;
}

             reply	other threads:[~2003-07-08 19:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-08 20:12 Guillaume Chazarain [this message]
2003-07-08 21:13 ` Davide Libenzi
2003-07-10  7:14 ` Guillaume Chazarain
2003-07-09  9:49 Guillaume Chazarain
2003-07-09 10:59 ` Marc-Christian Petersen
2003-07-09 15:59 ` Roberto Orenstein
     [not found] <WQ98NJGC3OMJH0887GC84IHIE856FA.3f0c5488@monpc>
2003-07-09 18:44 ` Roberto Orenstein

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=JFNL84UTSKFOJFDFD9D8GBF2WICKG.3f0b25af@monpc \
    --to=gfc@altern.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®