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
On Tue, 8 Jul 2003, Guillaume Chazarain wrote:
> 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.
I believe these are the bits that broke the scheduler, that was working
fine during the very first shots in 2.5. IIRC Ingo was hit by ppl
complains about those 'nice' rules and he had to fix it. It'd be
interesting bring back a more generous interactive bonus and see how the
scheduler behave.
- Davide
08/07/03 23:13:22, Davide Libenzi <[email protected]> wrote:
>On Tue, 8 Jul 2003, Guillaume Chazarain wrote:
>
>> 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.
>
>I believe these are the bits that broke the scheduler, that was working
>fine during the very first shots in 2.5. IIRC Ingo was hit by ppl
>complains about those 'nice' rules and he had to fix it. It'd be
>interesting bring back a more generous interactive bonus and see how the
>scheduler behave.
Thanks for the info.
Before being 25% the interactivity range was 70%, thus breaking the rules. So
I am now more convinced that a 50% range could be a good thing.
Here is the patch I currently use and am very happy with it.
--- linux-2.5.74-bk6/kernel/sched.c.old 2003-07-09 10:08:01.000000000 +0200
+++ linux-2.5.74-bk6/kernel/sched.c 2003-07-09 11:27:23.000000000 +0200
@@ -68,10 +68,10 @@
*/
#define MIN_TIMESLICE ( 10 * HZ / 1000)
#define MAX_TIMESLICE (200 * HZ / 1000)
-#define CHILD_PENALTY 50
-#define PARENT_PENALTY 100
+#define CHILD_PENALTY 80
+#define PARENT_PENALTY 90
#define EXIT_WEIGHT 3
-#define PRIO_BONUS_RATIO 25
+#define PRIO_BONUS_RATIO 45
#define INTERACTIVE_DELTA 2
#define MAX_SLEEP_AVG (10*HZ)
#define STARVATION_LIMIT (10*HZ)
@@ -88,13 +88,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.)
*
@@ -303,9 +303,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.
@@ -347,9 +347,9 @@
*/
static inline void activate_task(task_t *p, runqueue_t *rq)
{
- long sleep_time = jiffies - p->last_run - 1;
+ long sleep_time = jiffies - p->last_run;
- if (sleep_time > 0) {
+ if (p->state == TASK_INTERRUPTIBLE && sleep_time) {
int sleep_avg;
/*
The following change:
- long sleep_time = jiffies - p->last_run - 1;
+ long sleep_time = jiffies - p->last_run;
helps mplayer become interactive. Otherwise, it uses just a little fraction of the CPU,
and is considered a CPU hog.
My workload may not be representative of ordinary desktop use, so I'd like to have some
feedback on these simple changes. Of course these changes can be put on top of Con's work
in -mm3 with this patch.
--- linux-2.5.74-mm3/kernel/sched.c.old 2003-07-09 09:14:50.000000000 +0200
+++ linux-2.5.74-mm3/kernel/sched.c 2003-07-09 11:39:56.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)
@@ -386,9 +386,9 @@
*/
static inline void activate_task(task_t *p, runqueue_t *rq)
{
- long sleep_time = jiffies - p->last_run - 1;
+ long sleep_time = jiffies - p->last_run;
- if (sleep_time > 0) {
+ if (p->state == TASK_INTERRUPTIBLE && sleep_time) {
unsigned long runtime = jiffies - p->avg_start;
/*
Thanks.
Guillaume
On Wednesday 09 July 2003 11:49, Guillaume Chazarain wrote:
Hi Guillaume,
> --- linux-2.5.74-bk6/kernel/sched.c.old 2003-07-09 10:08:01.000000000 +0200
> +++ linux-2.5.74-bk6/kernel/sched.c 2003-07-09 11:27:23.000000000 +0200
> @@ -68,10 +68,10 @@
> */
> #define MIN_TIMESLICE ( 10 * HZ / 1000)
> #define MAX_TIMESLICE (200 * HZ / 1000)
> -#define CHILD_PENALTY 50
> -#define PARENT_PENALTY 100
> +#define CHILD_PENALTY 80
> +#define PARENT_PENALTY 90
> #define EXIT_WEIGHT 3
> -#define PRIO_BONUS_RATIO 25
> +#define PRIO_BONUS_RATIO 45
> #define INTERACTIVE_DELTA 2
> #define MAX_SLEEP_AVG (10*HZ)
> #define STARVATION_LIMIT (10*HZ)
> @@ -88,13 +88,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.)
> *
> @@ -303,9 +303,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.
> @@ -347,9 +347,9 @@
> */
> static inline void activate_task(task_t *p, runqueue_t *rq)
> {
> - long sleep_time = jiffies - p->last_run - 1;
> + long sleep_time = jiffies - p->last_run;
>
> - if (sleep_time > 0) {
> + if (p->state == TASK_INTERRUPTIBLE && sleep_time) {
> int sleep_avg;
>
> /*
>
I can't see & feel any good difference with this applied on top of .74-mm3
(slightly modified to apply)
> --- linux-2.5.74-mm3/kernel/sched.c.old 2003-07-09 09:14:50.000000000 +0200
> +++ linux-2.5.74-mm3/kernel/sched.c 2003-07-09 11:39:56.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)
> @@ -386,9 +386,9 @@
> */
> static inline void activate_task(task_t *p, runqueue_t *rq)
> {
> - long sleep_time = jiffies - p->last_run - 1;
> + long sleep_time = jiffies - p->last_run;
>
> - if (sleep_time > 0) {
> + if (p->state == TASK_INTERRUPTIBLE && sleep_time) {
> unsigned long runtime = jiffies - p->avg_start;
>
> /*
>
And I even cannot see and feel any good difference with that one ontop of
.74-mm3.
It's more worse than w/o:
Before the patch: mplayer was able to play a movie in fullscreen w/o any
framedrops while "make -j2 bzImage modules"
With the patch: mplayer stops for ~0.5 seconds every 5 seconds while "make -j2
bzImage modules"
You said the "long sleep_time = jiffies - p->last_run;" change helps mplayer?
Not in my case ;)
- Celeron 1,3GHz
- 512MB RAM
- 1GB SWAP (2 IDE disks, ~512MB on each disk)
- ATA100 Maxtor 60GB HDD
- ATA100 Fujitsu 40GB
ciao, Marc
On Wed, 2003-07-09 at 06:49, Guillaume Chazarain wrote:
> 08/07/03 23:13:22, Davide Libenzi <[email protected]> wrote:
>
> >On Tue, 8 Jul 2003, Guillaume Chazarain wrote:
> >
> >> 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.
> >
> >I believe these are the bits that broke the scheduler, that was working
> >fine during the very first shots in 2.5. IIRC Ingo was hit by ppl
> >complains about those 'nice' rules and he had to fix it. It'd be
> >interesting bring back a more generous interactive bonus and see how the
> >scheduler behave.
>
> Thanks for the info.
> Before being 25% the interactivity range was 70%, thus breaking the rules. So
> I am now more convinced that a 50% range could be a good thing.
>
Just a suggestion, why instead of changing the code you don't try the
attached patch? At least you don't have to recompile just to change a
few define's. Against 2.5.73, but applies in 2.5.74. Just the "long
sleep_time = jiffies - p->last_run;" isn't there.
I remember that I saw someone's patch nearly identical to this ( I think
it was Robert Love) but I don't remember the url.
On Wed, 2003-07-09 at 14:44, Guillaume Chazarain wrote:
> 09/07/03 17:59:10, Roberto Orenstein <[email protected]> wrote:
>
> >Just a suggestion, why instead of changing the code you don't try the
> >attached patch? At least you don't have to recompile just to change a
> >few define's. Against 2.5.73, but applies in 2.5.74. Just the "long
> >sleep_time = jiffies - p->last_run;" isn't there.
>
> Hi again,
>
> your patch oops on boot, here is a patch to correct that.
>
> Guillaume
>
Oops, thanks. Corrected patch below.
Anyway, I hope it helps.
regards,
Roberto
Hello,
here is the latest version of my simple patch.
I increased INTERACTIVE_DELTA to 4 as told me
Mike Galbraith, he also explained to me why
the p->state == TASK_INTERRUPTIBLE test was a bad thing.
The previous patch against -mm3 was an accident, it
messed my tweaks with Con's work and it was... cough
not tested...
I'd appreciate any feedback.
Thanks.
Guillaume
--- linux-2.5.74-bk7/kernel/sched.c.old 2003-07-09 10:08:01.000000000 +0200
+++ linux-2.5.74-bk7/kernel/sched.c 2003-07-10 00:35:59.000000000 +0200
@@ -68,11 +68,11 @@
*/
#define MIN_TIMESLICE ( 10 * HZ / 1000)
#define MAX_TIMESLICE (200 * HZ / 1000)
-#define CHILD_PENALTY 50
-#define PARENT_PENALTY 100
+#define CHILD_PENALTY 80
+#define PARENT_PENALTY 90
#define EXIT_WEIGHT 3
-#define PRIO_BONUS_RATIO 25
-#define INTERACTIVE_DELTA 2
+#define PRIO_BONUS_RATIO 45
+#define INTERACTIVE_DELTA 4
#define MAX_SLEEP_AVG (10*HZ)
#define STARVATION_LIMIT (10*HZ)
#define NODE_THRESHOLD 125
@@ -88,13 +88,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,0,0,0,0]
+ * TASK_INTERACTIVE(-10): [1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0]
+ * TASK_INTERACTIVE( 0): [1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0]
+ * TASK_INTERACTIVE( 10): [1,1,0,0,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.)
*
@@ -303,9 +303,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.
@@ -347,9 +347,9 @@
*/
static inline void activate_task(task_t *p, runqueue_t *rq)
{
- long sleep_time = jiffies - p->last_run - 1;
+ long sleep_time = jiffies - p->last_run;
- if (sleep_time > 0) {
+ if (sleep_time) {
int sleep_avg;
/*
@@ -361,15 +361,9 @@
* higher the priority boost gets as well.
*/
sleep_avg = p->sleep_avg + sleep_time;
-
- /*
- * 'Overflow' bonus ticks go to the waker as well, so the
- * ticks are not lost. This has the effect of further
- * boosting tasks that are related to maximum-interactive
- * tasks.
- */
if (sleep_avg > MAX_SLEEP_AVG)
sleep_avg = MAX_SLEEP_AVG;
+
if (p->sleep_avg != sleep_avg) {
p->sleep_avg = sleep_avg;
p->prio = effective_prio(p);