Messages in this thread Patches in this message | | | From | Guillaume Chazarain <> | Date | Tue, 08 Jul 2003 22:12:31 +0200 | Subject | [PATCH] Interactivity bits |
| |
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
[unhandled content-type:application/octet-stream] | |