Re: [RFC][PATCH] SCHED_ISO for interactivity

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Guillaume Chazarain]

Hi Con,

I am currently testing SCHED_ISO, but I have noticed a regression:
I do a make -j5 in linux-2.5.75/ everything is OK since gcc prio is 25.
X and fvwm prio are 15, but when I move a window it's very jerky.

And btw, as I am interested in scheduler improvements, do you have a testcase
where the stock scheduler does the bad thing? Preferably without KDE nor
Mozilla (I don't have them installed, and I'll have access to a decent
connection in september).

BTW2, you all seem to test interactivity with xmms. Just for those like me
that didn't noticed, I have just found that it skips much less with alsa's
OSS emulation than with alsa-xmms.


Thanks,
Guillaume

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Christian Axelsson]

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

On Sun, 2003-07-13 at 12:41, Guillaume Chazarain wrote:
> Hi Con,
> 
> I am currently testing SCHED_ISO, but I have noticed a regression:
> I do a make -j5 in linux-2.5.75/ everything is OK since gcc prio is 25.
> X and fvwm prio are 15, but when I move a window it's very jerky.

It's pretty smooth on my desktop (t-bird 1.4, 512mb ram, nvidia)

> BTW2, you all seem to test interactivity with xmms. Just for those like me
> that didn't noticed, I have just found that it skips much less with alsa's
> OSS emulation than with alsa-xmms.

I will try that out, seems to work so far, intressting...

-- 
Christian Axelsson
smiler@lanil.mine.nu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

On Sun, 13 Jul 2003 21:54, Christian Axelsson wrote:
> On Sun, 2003-07-13 at 12:41, Guillaume Chazarain wrote:
> > Hi Con,
> >
> > I am currently testing SCHED_ISO, but I have noticed a regression:
> > I do a make -j5 in linux-2.5.75/ everything is OK since gcc prio is 25.
> > X and fvwm prio are 15, but when I move a window it's very jerky.
>
> It's pretty smooth on my desktop (t-bird 1.4, 512mb ram, nvidia)

Probably faster hardware. I think I'll decrease the iso penalty to just 1/2 
sized timeslices (ISO_PENALTY 2)

> > BTW2, you all seem to test interactivity with xmms. Just for those like
> > me that didn't noticed, I have just found that it skips much less with
> > alsa's OSS emulation than with alsa-xmms.
>
> I will try that out, seems to work so far, intressting...

The logical conclusion of this idea where there is a dynamic policy assigned 
to interactive tasks is a dynamic policy assigned to non interactive tasks 
that get treated in the opposite way. I'll code something for that soon, now 
that I've had more feedback on the first part.

Con

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

On Tue, 15 Jul 2003 01:40, Guillaume Chazarain wrote:
> 14/07/03 02:07:34, Con Kolivas <kernel@kolivas.org> wrote:
> >On Mon, 14 Jul 2003 00:54, Guillaume Chazarain wrote:
> >> Good, with ISO_PENALTY == 2, I can smoothly move big windows (with
> >> ISO_PENALTY == 5 it was smooth only with very small windows), but it
> >> lets me move them smoothly during less time than stock :(
> >
> >Less time than stock? I don't understand you. You can only move them
> > smoothly for a small time or they move faster or... ?
>
> With the previous SCHED_ISO, moving big windows was smooth for a short
> time, but then it became jerky.  Unlike with stock where it was smooth all
> the time.
>
> >Indeed it is artificial, and probably never a real world condition unless
> > it was specifically an attack, but it would never bring the system to a
> > halt, just some minor audio hiccups while it adjusted.
>
> This is also true for stock.
>
> >> >The logical conclusion of this idea where there is a dynamic policy
> >> > assigned to interactive tasks is a dynamic policy assigned to non
> >> > interactive tasks that get treated in the opposite way. I'll code
> >> > something for that soon, now that I've had more feedback on the first
> >> > part.
> >>
> >> Interesting, let's see :)
> >> But as the interactive bonus can already be negative I wonder what use
> >> will have another variable.
> >
> >As it is, the penalty will be no different to what it currently gets to
> > (in the same way sched_iso get the same bonus they normally would). The
> > difference is once they are moved to the different policy it is much
> > harder for them to change from that state, always getting the maximum
> > penalty, and being expired each time they run out of timeslice instead of
> > getting a chance to be put onto the active array. Neither of these new
> > states is very different to what normal policy tasks get except for the
> > fact they dont change interactive state without a lot more effort.
>
> OK, the latest SCHED_ISO fixed my problem, but now I am afraid of the
> scheduler trying to be too intelligent, because if it makes the wrong
> choice the bad result will be much more noticeable.
> I like the simplicity of stock, the interactivity bonus is given in a
> simple and understandable way, and if it's not given to the process you
> want, you can always renice it or make it RT.

Yes I think I may be chasing my own tail with this work and should probably 
concentrate on what has been working...

>
> I have to admit that
> p->sleep_avg = MIN_SLEEP_AVG * (MAX_BONUS - INTERACTIVE_DELTA - 1) /
> MAX_BONUS; and
> if ((runtime - MIN_SLEEP_AVG < MAX_SLEEP_AVG) && (runtime *
> JUST_INTERACTIVE > p->sleep_avg)) p->sleep_avg += (runtime *
> JUST_INTERACTIVE - p->sleep_avg) *
> 	                (MAX_SLEEP_AVG + MIN_SLEEP_AVG - runtime) / MAX_SLEEP_AVG;
>
> are quite obscure to me.

If the patch ever stabilises I'll post an RFC explaining as much as possible.

>
> Also, I don't understand your MAX_BONUS definition:
> ((MAX_USER_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100) it evaluates to
> -15
>
> I would use ((MAX_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100 / 2) since
> it gives 5.

I was trying to preserve Ingo's code style where it still existed...

I'll concentrate on the O*int patches because they are less invasive. This 
approach has the problem you described:
> scheduler trying to be too intelligent, because if it makes the wrong
> choice the bad result will be much more noticeable.
and it will never be smart enough...

Con

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Guillaume Chazarain]

14/07/03 02:07:34, Con Kolivas <kernel@kolivas.org> wrote:
>On Mon, 14 Jul 2003 00:54, Guillaume Chazarain wrote:
>> Good, with ISO_PENALTY == 2, I can smoothly move big windows (with
>> ISO_PENALTY == 5 it was smooth only with very small windows), but it lets
>> me move them smoothly during less time than stock :(
>
>Less time than stock? I don't understand you. You can only move them smoothly 
>for a small time or they move faster or... ?

With the previous SCHED_ISO, moving big windows was smooth for a short time,
but then it became jerky.  Unlike with stock where it was smooth all the time.

>Indeed it is artificial, and probably never a real world condition unless it 
>was specifically an attack, but it would never bring the system to a halt, 
>just some minor audio hiccups while it adjusted. 

This is also true for stock.

>> >The logical conclusion of this idea where there is a dynamic policy
>> > assigned to interactive tasks is a dynamic policy assigned to non
>> > interactive tasks that get treated in the opposite way. I'll code
>> > something for that soon, now that I've had more feedback on the first
>> > part.
>>
>> Interesting, let's see :)
>> But as the interactive bonus can already be negative I wonder what use
>> will have another variable.
>
>As it is, the penalty will be no different to what it currently gets to (in 
>the same way sched_iso get the same bonus they normally would). The 
>difference is once they are moved to the different policy it is much harder 
>for them to change from that state, always getting the maximum penalty, and 
>being expired each time they run out of timeslice instead of getting a chance 
>to be put onto the active array. Neither of these new states is very 
>different to what normal policy tasks get except for the fact they dont 
>change interactive state without a lot more effort.

OK, the latest SCHED_ISO fixed my problem, but now I am afraid of the scheduler
trying to be too intelligent, because if it makes the wrong choice the bad result
will be much more noticeable.
I like the simplicity of stock, the interactivity bonus is given in a simple and
understandable way, and if it's not given to the process you want, you can always
renice it or make it RT.

I have to admit that
p->sleep_avg = MIN_SLEEP_AVG * (MAX_BONUS - INTERACTIVE_DELTA - 1) / MAX_BONUS;
and
if ((runtime - MIN_SLEEP_AVG < MAX_SLEEP_AVG) && (runtime * JUST_INTERACTIVE > p->sleep_avg))
	p->sleep_avg += (runtime * JUST_INTERACTIVE - p->sleep_avg) *
	                (MAX_SLEEP_AVG + MIN_SLEEP_AVG - runtime) / MAX_SLEEP_AVG;

are quite obscure to me.

Also, I don't understand your MAX_BONUS definition:
((MAX_USER_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100) it evaluates to -15

I would use ((MAX_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100 / 2) since it gives 5.


Guillaume

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

On Mon, 14 Jul 2003 00:54, Guillaume Chazarain wrote:
> 13/07/03 14:53:12, Con Kolivas <kernel@kolivas.org> wrote:
> >On Sun, 13 Jul 2003 20:41, Guillaume Chazarain wrote:
> Good, with ISO_PENALTY == 2, I can smoothly move big windows (with
> ISO_PENALTY == 5 it was smooth only with very small windows), but it lets
> me move them smoothly during less time than stock :(

I think I know what you mean now. Expiring X hurts. With a penalty of only 2
it should be unecessary to expire iso tasks. Addressed below.

> >The logical conclusion of this idea where there is a dynamic policy
> > assigned to interactive tasks is a dynamic policy assigned to non
> > interactive tasks that get treated in the opposite way. I'll code
> > something for that soon, now that I've had more feedback on the first
> > part.
>
> Interesting, let's see :)
> But as the interactive bonus can already be negative I wonder what use
> will have another variable.

The added feature of expiring them every time they use up their timeslice
should help.

An updated patch-SI-0307141335 against 2.5.75-mm1 incorporating these
changes and more tweaks is here:
http://kernel.kolivas.org/2.5/

and here:
patch-SI-0307141335
--------------------------------
diff -Naurp linux-2.5.75-mm1/include/linux/sched.h linux-2.5.75-test/include/linux/sched.h
--- linux-2.5.75-mm1/include/linux/sched.h	2003-07-13 00:21:30.000000000 +1000
+++ linux-2.5.75-test/include/linux/sched.h	2003-07-14 13:50:01.000000000 +1000
@@ -125,6 +125,8 @@ extern unsigned long nr_iowait(void);
 #define SCHED_NORMAL		0
 #define SCHED_FIFO		1
 #define SCHED_RR		2
+#define SCHED_BATCH		3
+#define SCHED_ISO		4
 
 struct sched_param {
 	int sched_priority;
diff -Naurp linux-2.5.75-mm1/kernel/exit.c linux-2.5.75-test/kernel/exit.c
--- linux-2.5.75-mm1/kernel/exit.c	2003-07-13 00:21:30.000000000 +1000
+++ linux-2.5.75-test/kernel/exit.c	2003-07-14 13:33:42.000000000 +1000
@@ -223,7 +223,7 @@ void reparent_to_init(void)
 	/* Set the exit signal to SIGCHLD so we signal init on exit */
 	current->exit_signal = SIGCHLD;
 
-	if ((current->policy == SCHED_NORMAL) && (task_nice(current) < 0))
+	if ((current->policy == SCHED_NORMAL || current->policy == SCHED_ISO || current->policy == SCHED_BATCH) && (task_nice(current) < 0))
 		set_user_nice(current, 0);
 	/* cpus_allowed? */
 	/* rt_priority? */
diff -Naurp linux-2.5.75-mm1/kernel/sched.c linux-2.5.75-test/kernel/sched.c
--- linux-2.5.75-mm1/kernel/sched.c	2003-07-13 00:21:30.000000000 +1000
+++ linux-2.5.75-test/kernel/sched.c	2003-07-14 13:41:55.000000000 +1000
@@ -74,12 +74,12 @@
 #define PRIO_BONUS_RATIO	25
 #define INTERACTIVE_DELTA	2
 #define MIN_SLEEP_AVG		(HZ)
-#define MAX_SLEEP_AVG		(10*HZ)
-#define STARVATION_LIMIT	(10*HZ)
-#define SLEEP_BUFFER		(HZ/20)
+#define MAX_SLEEP_AVG		(5*HZ)
+#define STARVATION_LIMIT	(5*HZ)
+#define ISO_PENALTY		(2)
 #define NODE_THRESHOLD		125
 #define MAX_BONUS		((MAX_USER_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100)
-
+#define JUST_INTERACTIVE	(MAX_BONUS - INTERACTIVE_DELTA) / MAX_BONUS
 /*
  * If a task is 'interactive' then we reinsert it in the active
  * array after it has expired its current timeslice. (it will not
@@ -118,6 +118,10 @@
 #define TASK_INTERACTIVE(p) \
 	((p)->prio <= (p)->static_prio - DELTA(p))
 
+#define normal_task(p)		((p)->policy == SCHED_NORMAL)
+#define iso_task(p)		((p)->policy == SCHED_ISO)
+#define batch_task(p)		((p)->policy == SCHED_BATCH)
+
 /*
  * BASE_TIMESLICE scales user-nice values [ -20 ... 19 ]
  * to time slice values.
@@ -134,7 +138,16 @@
 
 static inline unsigned int task_timeslice(task_t *p)
 {
-	return BASE_TIMESLICE(p);
+	if (!iso_task(p))
+		return (BASE_TIMESLICE(p));
+	else {
+		int timeslice = BASE_TIMESLICE(p) / ISO_PENALTY;
+
+		if (timeslice < MIN_TIMESLICE)
+			timeslice = MIN_TIMESLICE;
+
+		return timeslice;
+	}
 }
 
 /*
@@ -319,6 +332,14 @@ static inline void normalise_sleep(task_
 
 	p->sleep_avg = p->sleep_avg * MIN_SLEEP_AVG / old_avg_time;
 	p->avg_start = jiffies - MIN_SLEEP_AVG;
+
+	/*
+	 * New children and their parents are not allowed to
+	 * be SCHED_ISO or SCHED_BATCH.
+	 */
+	if (iso_task(p) || batch_task(p))
+		p->policy = SCHED_NORMAL;
+
 }
 
 /*
@@ -343,26 +364,38 @@ static int effective_prio(task_t *p)
 	if (rt_task(p))
 		return p->prio;
 
-	sleep_period = jiffies - p->avg_start;
+	/*
+	 * SCHED_BATCH tasks end up getting the maximum penalty
+	 */
+	bonus = - MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
 
-	if (unlikely(!sleep_period))
-		return p->static_prio;
+	if (normal_task(p)){
+		sleep_period = jiffies - p->avg_start;
 
-	if (sleep_period > MAX_SLEEP_AVG)
-		sleep_period = MAX_SLEEP_AVG;
+		if (unlikely(!sleep_period))
+			return p->static_prio;
 
-	if (p->sleep_avg > sleep_period)
-		sleep_period = p->sleep_avg;
+		if (sleep_period > MAX_SLEEP_AVG)
+			sleep_period = MAX_SLEEP_AVG;
 
-	/*
-	 * The bonus is determined according to the accumulated
-	 * sleep avg over the duration the task has been running
-	 * until it reaches MAX_SLEEP_AVG. -ck
-	 */
-	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100 -
-			MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
+		if (p->sleep_avg > sleep_period)
+			sleep_period = p->sleep_avg;
+
+		/*
+		 * The bonus is determined according to the accumulated
+		 * sleep avg over the duration the task has been running
+		 * until it reaches MAX_SLEEP_AVG. -ck
+		 */
+		bonus += MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100;
+
+	} else if (iso_task(p))
+		/*
+		 * SCHED_ISO tasks get the maximum possible bonus
+		 */
+		bonus += MAX_USER_PRIO*PRIO_BONUS_RATIO/100;
 
 	prio = p->static_prio - bonus;
+
 	if (prio < MAX_RT_PRIO)
 		prio = MAX_RT_PRIO;
 	if (prio > MAX_PRIO-1)
@@ -398,6 +431,11 @@ static inline void activate_task(task_t 
 		 * to allow them to become interactive or non-interactive rapidly
 		 */
 		if (sleep_time > MIN_SLEEP_AVG){
+			/*
+			 * Idle tasks can not be SCHED_ISO or SCHED_BATCH
+			 */
+			if (iso_task(p) || batch_task(p))
+				p->policy = SCHED_NORMAL;
 			p->avg_start = jiffies - MIN_SLEEP_AVG;
 			p->sleep_avg = MIN_SLEEP_AVG * (MAX_BONUS - INTERACTIVE_DELTA - 1) /
 				MAX_BONUS;
@@ -417,25 +455,45 @@ static inline void activate_task(task_t 
 			 * the problem of the denominator in the bonus equation
 			 * from continually getting larger.
 			 */
-			if ((runtime - MIN_SLEEP_AVG) < MAX_SLEEP_AVG)
-				p->sleep_avg += (runtime - p->sleep_avg) *
-					(MAX_SLEEP_AVG + MIN_SLEEP_AVG - runtime) *
-					(MAX_BONUS - INTERACTIVE_DELTA) / MAX_BONUS / MAX_SLEEP_AVG;
+
+			if ((runtime - MIN_SLEEP_AVG < MAX_SLEEP_AVG) && (runtime * JUST_INTERACTIVE > p->sleep_avg))
+				p->sleep_avg += (runtime * JUST_INTERACTIVE - p->sleep_avg) *
+					(MAX_SLEEP_AVG + MIN_SLEEP_AVG - runtime) / MAX_SLEEP_AVG;
+
+			if (p->sleep_avg > MAX_SLEEP_AVG){
+				/*
+				 * Tasks that have slept more than MAX_SLEEP_AVG
+				 * become SCHED_ISO tasks.
+				 */
+				if (normal_task(p))
+					p->policy = SCHED_ISO;
+				else if (unlikely(batch_task(p)))
+					p->policy = SCHED_NORMAL;
+
+				p->sleep_avg = MAX_SLEEP_AVG;
+			}
 
 			/*
-			 * Keep a small buffer of SLEEP_BUFFER sleep_avg to
-			 * prevent fully interactive tasks from becoming
-			 * lower priority with small bursts of cpu usage.
+			 * Just in case a SCHED_ISO task has become a complete
+			 * cpu hog revert it to SCHED_NORMAL
 			 */
-			if (p->sleep_avg > (MAX_SLEEP_AVG + SLEEP_BUFFER))
-				p->sleep_avg = MAX_SLEEP_AVG + SLEEP_BUFFER;
+			if (unlikely(!p->sleep_avg && iso_task(p))){
+				p->policy = SCHED_NORMAL;
+				p->avg_start = jiffies;
+			}
 		}
 
 		if (unlikely(p->avg_start > jiffies)){
 			p->avg_start = jiffies;
 			p->sleep_avg = 0;
 		}
-	}
+	/*
+	 * SCHED_NORMAL tasks that have used up all their sleep avg
+	 * get demoted to SCHED_BATCH
+	 */
+	} else if (!p->sleep_avg && normal_task(p))
+			p->policy = SCHED_BATCH;
+
 	p->prio = effective_prio(p);
 	__activate_task(p, rq);
 }
@@ -1309,13 +1367,20 @@ void scheduler_tick(int user_ticks, int 
 		p->time_slice = task_timeslice(p);
 		p->first_time_slice = 0;
 
-		if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq)) {
+		/*
+		 * SCHED_BATCH tasks always get expired if they use up their
+		 * timeslice.
+		 * If SCHED_ISO tasks are using too much cpu time they
+		 * enter the expired array.
+		 */
+		if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq) || batch_task(p)) {
 			if (!rq->expired_timestamp)
 				rq->expired_timestamp = jiffies;
 			enqueue_task(p, rq->expired);
 		} else
 			enqueue_task(p, rq->active);
 	}
+
 out_unlock:
 	spin_unlock(&rq->lock);
 out:
@@ -1818,8 +1883,8 @@ static int setscheduler(pid_t pid, int p
 		policy = p->policy;
 	else {
 		retval = -EINVAL;
-		if (policy != SCHED_FIFO && policy != SCHED_RR &&
-				policy != SCHED_NORMAL)
+		if (policy != SCHED_FIFO && policy != SCHED_RR && policy != SCHED_BATCH &&
+				policy != SCHED_NORMAL && policy != SCHED_ISO)
 			goto out_unlock;
 	}
 
@@ -1830,7 +1895,7 @@ static int setscheduler(pid_t pid, int p
 	retval = -EINVAL;
 	if (lp.sched_priority < 0 || lp.sched_priority > MAX_USER_RT_PRIO-1)
 		goto out_unlock;
-	if ((policy == SCHED_NORMAL) != (lp.sched_priority == 0))
+	if ((policy == SCHED_NORMAL || policy == SCHED_ISO || policy == SCHED_BATCH) != (lp.sched_priority == 0))
 		goto out_unlock;
 
 	retval = -EPERM;
@@ -1852,7 +1917,7 @@ static int setscheduler(pid_t pid, int p
 	p->policy = policy;
 	p->rt_priority = lp.sched_priority;
 	oldprio = p->prio;
-	if (policy != SCHED_NORMAL)
+	if (policy == SCHED_FIFO || policy == SCHED_RR)
 		p->prio = MAX_USER_RT_PRIO-1 - p->rt_priority;
 	else
 		p->prio = p->static_prio;
@@ -2151,6 +2216,8 @@ asmlinkage long sys_sched_get_priority_m
 		ret = MAX_USER_RT_PRIO-1;
 		break;
 	case SCHED_NORMAL:
+	case SCHED_ISO:
+	case SCHED_BATCH:
 		ret = 0;
 		break;
 	}
@@ -2174,6 +2241,8 @@ asmlinkage long sys_sched_get_priority_m
 		ret = 1;
 		break;
 	case SCHED_NORMAL:
+	case SCHED_ISO:
+	case SCHED_BATCH:
 		ret = 0;
 	}
 	return ret;

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Daniel Phillips]

On Monday 14 July 2003 02:13, Con Kolivas wrote:
> On Mon, 14 Jul 2003 06:03, Daniel Phillips wrote:
> I'm not looking at creating a true realtime policy of any sort. Mine is
> more a dynamic policy change to an interactive state that is sustained,

That's clear.

> which gives no more capabilities to a normal user process than they can
> currently get on SCHED_NORMAL tasks. Audio will definitely get priority...

If you mean it will get a quick boost when it needs it, the trouble is, audio 
doesn't need that just sometimes, it needs it all the time.  Hence, the 
tweaks you're doing are fundamentally unable to deliver the kind of audio 
reliablity we'd like to become used to.  That's not to denigrate the value of 
your approach: it does seem to produce good effects in terms of interactive 
response, but it's not a cure-all.

> along with any other interactive task, but not in a real time fashion.
> Basically they effectively get a nice -5 unless they do the wrong thing.

Yes, I noticed pretty quickly that if I wanted to get rid of the audio 
glitches by renicing, I had to use nice -5 or lower.

Regards,

Daniel

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

On Mon, 14 Jul 2003 06:03, Daniel Phillips wrote:
> On Saturday 12 July 2003 17:49, William Lee Irwin III wrote:
> > On Fri, Jul 11, 2003 at 08:53:38PM +1000, Con Kolivas wrote:
> > > Wli coined the term "isochronous" (greek for same time) for a real time
> > > task that was limited in it's timeslice but still guaranteed to run.
> > > I've decided to abuse this term and use it to name this new policy in
> > > this patch. This is neither real time, nor guaranteed.
> >
> > I didn't coin it; I know of it from elsewhere.
>
> Right, for example, USB has an isochronous transfer facility intended to
> support media applications, e.g., cameras, that require realtime
> bandwidth/latency guarantees.  The thing is, such guarantees have to be
> end-to-end in the media pipeline.  Sound is just one of the applications
> that needs the kind of realtime support we (or more properly, Davide) just
> proposed.

I'm not looking at creating a true realtime policy of any sort. Mine is more a 
dynamic policy change to an interactive state that is sustained, which gives 
no more capabilities to a normal user process than they can currently get on 
SCHED_NORMAL tasks. Audio will definitely get priority... along with any 
other interactive task, but not in a real time fashion. Basically they 
effectively get a nice -5 unless they do the wrong thing.

Con

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

On Mon, 14 Jul 2003 00:54, Guillaume Chazarain wrote:
> 13/07/03 14:53:12, Con Kolivas <kernel@kolivas.org> wrote:
> >On Sun, 13 Jul 2003 20:41, Guillaume Chazarain wrote:
> >> Hi Con,
> >>
> >> I am currently testing SCHED_ISO, but I have noticed a regression:
> >> I do a make -j5 in linux-2.5.75/ everything is OK since gcc prio is 25.
> >> X and fvwm prio are 15, but when I move a window it's very jerky.
> >
> >Interesting. I don't know how much smaller the timeslice can be before
> >different hardware will be affected. Can you report what cpu and video
> > card you're using? Unfortunately I don't have a range of hardware to test
> > it on and I chose the aggressive 1/5th timeslice size. Can you try with
> > ISO_PENALTY set to 2 instead?
>
> Pentium3 450, 320 Mo RAM, Voodoo Banshee
>
> Good, with ISO_PENALTY == 2, I can smoothly move big windows (with
> ISO_PENALTY == 5 it was smooth only with very small windows), but it lets
> me move them smoothly during less time than stock :(

Less time than stock? I don't understand you. You can only move them smoothly 
for a small time or they move faster or... ?

> >> And btw, as I am interested in scheduler improvements, do you have a
> >> testcase where the stock scheduler does the bad thing? Preferably
> >> without KDE nor Mozilla (I don't have them installed, and I'll have
> >> access to a decent connection in september).
> >
> >Transparency and antialiased fonts are good triggers. Launcing Xterm with
> >transparency has been known to cause skips. Also the obvious make -j 4
> > kernel compiles, and
> >while true ; do a=2 ; done
> >as a fast onset full cpu hog
>
> Well, I had a hard time at making xmms skip with a transparent
> gnome-terminal. I could easily make xmms skip with this, but it's quite
> artificial.

Indeed it is artificial, and probably never a real world condition unless it 
was specifically an attack, but it would never bring the system to a halt, 
just some minor audio hiccups while it adjusted. 

> >The logical conclusion of this idea where there is a dynamic policy
> > assigned to interactive tasks is a dynamic policy assigned to non
> > interactive tasks that get treated in the opposite way. I'll code
> > something for that soon, now that I've had more feedback on the first
> > part.
>
> Interesting, let's see :)
> But as the interactive bonus can already be negative I wonder what use
> will have another variable.

As it is, the penalty will be no different to what it currently gets to (in 
the same way sched_iso get the same bonus they normally would). The 
difference is once they are moved to the different policy it is much harder 
for them to change from that state, always getting the maximum penalty, and 
being expired each time they run out of timeslice instead of getting a chance 
to be put onto the active array. Neither of these new states is very 
different to what normal policy tasks get except for the fact they dont 
change interactive state without a lot more effort.

Con

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Daniel Phillips]

On Sunday 13 July 2003 04:26, Con Kolivas wrote:
> Surprisingly noone has said whether this patch does any good for their
> setup though.

Sorry, I'm on the road for a month, it's rather difficult for me to continue 
my testing.  On the other hand, it's a good chance to read and hopefully 
understand your code.

Regards,

Daniel

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Daniel Phillips]

On Saturday 12 July 2003 17:49, William Lee Irwin III wrote:
> On Fri, Jul 11, 2003 at 08:53:38PM +1000, Con Kolivas wrote:
> > Wli coined the term "isochronous" (greek for same time) for a real time
> > task that was limited in it's timeslice but still guaranteed to run. I've
> > decided to abuse this term and use it to name this new policy in this
> > patch. This is neither real time, nor guaranteed.
>
> I didn't coin it; I know of it from elsewhere.

Right, for example, USB has an isochronous transfer facility intended to 
support media applications, e.g., cameras, that require realtime 
bandwidth/latency guarantees.  The thing is, such guarantees have to be 
end-to-end in the media pipeline.  Sound is just one of the applications that 
needs the kind of realtime support we (or more properly, Davide) just 
proposed.

Regards,

Daniel

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Guillaume Chazarain]

13/07/03 14:53:12, Con Kolivas <kernel@kolivas.org> wrote:

>On Sun, 13 Jul 2003 20:41, Guillaume Chazarain wrote:
>> Hi Con,
>>
>> I am currently testing SCHED_ISO, but I have noticed a regression:
>> I do a make -j5 in linux-2.5.75/ everything is OK since gcc prio is 25.
>> X and fvwm prio are 15, but when I move a window it's very jerky.
>
>Interesting. I don't know how much smaller the timeslice can be before 
>different hardware will be affected. Can you report what cpu and video card 
>you're using? Unfortunately I don't have a range of hardware to test it on 
>and I chose the aggressive 1/5th timeslice size. Can you try with ISO_PENALTY 
>set to 2 instead?

Pentium3 450, 320 Mo RAM, Voodoo Banshee

Good, with ISO_PENALTY == 2, I can smoothly move big windows (with ISO_PENALTY == 5
it was smooth only with very small windows), but it lets me move them smoothly
during less time than stock :(

>> And btw, as I am interested in scheduler improvements, do you have a
>> testcase where the stock scheduler does the bad thing? Preferably without
>> KDE nor Mozilla (I don't have them installed, and I'll have access to a
>> decent connection in september).
>
>Transparency and antialiased fonts are good triggers. Launcing Xterm with 
>transparency has been known to cause skips. Also the obvious make -j 4 kernel 
>compiles, and 
>while true ; do a=2 ; done
>as a fast onset full cpu hog

Well, I had a hard time at making xmms skip with a transparent gnome-terminal.
I could easily make xmms skip with this, but it's quite artificial.

#include <sys/types.h>
#include <stdio.h>
#include <time.h>
#include <unistd.h>

/* Should be near MAX_SLEEP_AVG. */
#define DELAY 20

/* With how many processes, will xmms resist? */
#define NPROC 4

int main(void)
{
    int i;
    pid_t the_pid, my_pid;

    the_pid = getpid();

    /* Make some friends. */
    for (i = 1; i < NPROC; i++)
        if (fork())
            break;

    my_pid = getpid();

    for (;;) {
        /* Wait, gain interactivity. */
        for (i = DELAY; i >= 0; i--) {
            if (the_pid == my_pid)
                printf("%d\n", i);
            sleep(1);
        }

        /* Attack! */
        if (my_pid == the_pid)
            puts("attack");
        for (i = 0; i < 100000000; i++);
    }

    return 0;
}

>The logical conclusion of this idea where there is a dynamic policy assigned 
>to interactive tasks is a dynamic policy assigned to non interactive tasks 
>that get treated in the opposite way. I'll code something for that soon, now 
>that I've had more feedback on the first part.

Interesting, let's see :)
But as the interactive bonus can already be negative I wonder what use
will have another variable.


Guillaume

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

On Sun, 13 Jul 2003 20:41, Guillaume Chazarain wrote:
> Hi Con,
>
> I am currently testing SCHED_ISO, but I have noticed a regression:
> I do a make -j5 in linux-2.5.75/ everything is OK since gcc prio is 25.
> X and fvwm prio are 15, but when I move a window it's very jerky.

Interesting. I don't know how much smaller the timeslice can be before 
different hardware will be affected. Can you report what cpu and video card 
you're using? Unfortunately I don't have a range of hardware to test it on 
and I chose the aggressive 1/5th timeslice size. Can you try with ISO_PENALTY 
set to 2 instead?

> And btw, as I am interested in scheduler improvements, do you have a
> testcase where the stock scheduler does the bad thing? Preferably without
> KDE nor Mozilla (I don't have them installed, and I'll have access to a
> decent connection in september).

Transparency and antialiased fonts are good triggers. Launcing Xterm with 
transparency has been known to cause skips. Also the obvious make -j 4 kernel 
compiles, and 
while true ; do a=2 ; done
as a fast onset full cpu hog

> BTW2, you all seem to test interactivity with xmms. Just for those like me
> that didn't noticed, I have just found that it skips much less with alsa's
> OSS emulation than with alsa-xmms.

Anything that increases the signal to noise ratio at helping us pick up 
skips/problems is useful, but this can help those that _don't_ want skips so 
thanks.

> Thanks,

Thank you very much for testing and reporting.

Con

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Christian Axelsson]

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

On Sun, 2003-07-13 at 04:26, Con Kolivas wrote:
> On Sun, 13 Jul 2003 02:28, Christian Axelsson wrote:
> > On Sat, 2003-07-12 at 17:39, Con Kolivas wrote:
> > > On Sat, 12 Jul 2003 10:13, Con Kolivas wrote:
> > > > On Sat, 12 Jul 2003 09:37, Christian Axelsson wrote:
> > > > > On Fri, 2003-07-11 at 16:30, Con Kolivas wrote:
> > > > > > On Fri, 11 Jul 2003 22:48, Christian Axelsson wrote:
> > >
> > > snip snip snip
> > >
> > > Mike G suggested expiring tasks which use up too much cpu
> > > time like in Davide's softrr patch which is a much better
> > > solution to the forever reinserted into the active array concern.
> > >
> > > patch-SI-0307130021 is also available at
> > > http://kernel.kolivas.org/2.5
> >
> > Problem seems to be gone (cant be 100% sure as I aint really sure WHAT
> > trigged this behavior).
> 
> I'm as close to sure as I can be since this addressed it. Thanks to your 
> feedback I would not have been able to figure it out or even know it was an 
> issue. 
> 
> Surprisingly noone has said whether this patch does any good for their setup 
> though.

I do feel an improvement, I get less of those annoying
alsa-bufferunderrun messages popping up from xmms while doing stuff but
it do still happen every now and then, mostly when working with
evolution or mozilla-firebird. 
I actually this has more with memory to do as if I leave computer idle
for a few hours stuff tends to get swapped out. IE 126mb of X is swapped
out and over 100mb of vmware and even almost 100% of firebird.

-- 
Christian Axelsson
smiler@lanil.mine.nu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

On Sun, 13 Jul 2003 02:28, Christian Axelsson wrote:
> On Sat, 2003-07-12 at 17:39, Con Kolivas wrote:
> > On Sat, 12 Jul 2003 10:13, Con Kolivas wrote:
> > > On Sat, 12 Jul 2003 09:37, Christian Axelsson wrote:
> > > > On Fri, 2003-07-11 at 16:30, Con Kolivas wrote:
> > > > > On Fri, 11 Jul 2003 22:48, Christian Axelsson wrote:
> >
> > snip snip snip
> >
> > Mike G suggested expiring tasks which use up too much cpu
> > time like in Davide's softrr patch which is a much better
> > solution to the forever reinserted into the active array concern.
> >
> > patch-SI-0307130021 is also available at
> > http://kernel.kolivas.org/2.5
>
> Problem seems to be gone (cant be 100% sure as I aint really sure WHAT
> trigged this behavior).

I'm as close to sure as I can be since this addressed it. Thanks to your 
feedback I would not have been able to figure it out or even know it was an 
issue. 

Surprisingly noone has said whether this patch does any good for their setup 
though.

Con

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Christian Axelsson]

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

On Sat, 2003-07-12 at 17:39, Con Kolivas wrote:
> On Sat, 12 Jul 2003 10:13, Con Kolivas wrote:
> > On Sat, 12 Jul 2003 09:37, Christian Axelsson wrote:
> > > On Fri, 2003-07-11 at 16:30, Con Kolivas wrote:
> > > > On Fri, 11 Jul 2003 22:48, Christian Axelsson wrote:
> snip snip snip
> 
> Mike G suggested expiring tasks which use up too much cpu
> time like in Davide's softrr patch which is a much better 
> solution to the forever reinserted into the active array concern.
> 
> patch-SI-0307130021 is also available at 
> http://kernel.kolivas.org/2.5

Problem seems to be gone (cant be 100% sure as I aint really sure WHAT
trigged this behavior).

-- 
Christian Axelsson
smiler@lanil.mine.nu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 12 July 2003 17:39, Con Kolivas wrote:
[SNIP]
> @@ -2153,6 +2208,9 @@ asmlinkage long sys_sched_get_priority_m
>  	case SCHED_NORMAL:
>  		ret = 0;
>  		break;
> +	case SCHED_ISO:
> +		ret = 0;
> +		break;
>  	}
>  	return ret;
>  }
> @@ -2175,6 +2233,8 @@ asmlinkage long sys_sched_get_priority_m
>  		break;
>  	case SCHED_NORMAL:
>  		ret = 0;
> +	case SCHED_ISO:
> +		ret = 0;
>  	}
>  	return ret;
>  }

As far, as I can see, this would do the very same
things, with reduced codesize:

 	case SCHED_NORMAL:
+	case SCHED_ISO:
 		ret = 0;
 		break;
 	}
 	return ret;
 }


and this:

 		break;
 	case SCHED_NORMAL:
+	case SCHED_ISO:
 		ret = 0;
 	}
 	return ret;
 }


- --
Regards Michael Buesch
http://www.8ung.at/tuxsoft
 18:22:51 up 49 min,  2 users,  load average: 2.14, 2.32, 2.31

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/EDbdoxoigfggmSgRAgFpAJ9Iz71qcgIFEM8mYIY9Xrw9Yn5BfQCeLZf3
5h47aU7gAzFYYrdLVS0RVZ8=
=drFI
-----END PGP SIGNATURE-----

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

On Sun, 13 Jul 2003 01:49, William Lee Irwin III wrote:
> On Fri, Jul 11, 2003 at 08:53:38PM +1000, Con Kolivas wrote:
> > Wli coined the term "isochronous" (greek for same time) for a real time
> > task that was limited in it's timeslice but still guaranteed to run. I've
> > decided to abuse this term and use it to name this new policy in this
> > patch. This is neither real time, nor guaranteed.
>
> I didn't coin it; I know of it from elsewhere.

s/coined/informed me of

Con

Re: [RFC][PATCH] SCHED_ISO for interactivity

[William Lee Irwin III]

On Fri, Jul 11, 2003 at 08:53:38PM +1000, Con Kolivas wrote:
> Wli coined the term "isochronous" (greek for same time) for a real time task 
> that was limited in it's timeslice but still guaranteed to run. I've decided 
> to abuse this term and use it to name this new policy in this patch. This is 
> neither real time, nor guaranteed.

I didn't coin it; I know of it from elsewhere.


-- wli

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

On Sat, 12 Jul 2003 10:13, Con Kolivas wrote:
> On Sat, 12 Jul 2003 09:37, Christian Axelsson wrote:
> > On Fri, 2003-07-11 at 16:30, Con Kolivas wrote:
> > > On Fri, 11 Jul 2003 22:48, Christian Axelsson wrote:
snip snip snip

Mike G suggested expiring tasks which use up too much cpu
time like in Davide's softrr patch which is a much better 
solution to the forever reinserted into the active array concern.

patch-SI-0307130021 is also available at 
http://kernel.kolivas.org/2.5

Con

diff -Naurp linux-2.5.75-mm1/include/linux/sched.h linux-2.5.75-test/include/linux/sched.h
--- linux-2.5.75-mm1/include/linux/sched.h	2003-07-13 00:21:30.000000000 +1000
+++ linux-2.5.75-test/include/linux/sched.h	2003-07-12 00:05:00.000000000 +1000
@@ -125,6 +125,7 @@ extern unsigned long nr_iowait(void);
 #define SCHED_NORMAL		0
 #define SCHED_FIFO		1
 #define SCHED_RR		2
+#define SCHED_ISO		3
 
 struct sched_param {
 	int sched_priority;
diff -Naurp linux-2.5.75-mm1/kernel/exit.c linux-2.5.75-test/kernel/exit.c
--- linux-2.5.75-mm1/kernel/exit.c	2003-07-13 00:21:30.000000000 +1000
+++ linux-2.5.75-test/kernel/exit.c	2003-07-12 00:05:00.000000000 +1000
@@ -223,7 +223,7 @@ void reparent_to_init(void)
 	/* Set the exit signal to SIGCHLD so we signal init on exit */
 	current->exit_signal = SIGCHLD;
 
-	if ((current->policy == SCHED_NORMAL) && (task_nice(current) < 0))
+	if ((current->policy == SCHED_NORMAL || current->policy == SCHED_ISO) && (task_nice(current) < 0))
 		set_user_nice(current, 0);
 	/* cpus_allowed? */
 	/* rt_priority? */
diff -Naurp linux-2.5.75-mm1/kernel/sched.c linux-2.5.75-test/kernel/sched.c
--- linux-2.5.75-mm1/kernel/sched.c	2003-07-13 00:21:30.000000000 +1000
+++ linux-2.5.75-test/kernel/sched.c	2003-07-13 00:48:15.000000000 +1000
@@ -76,9 +76,9 @@
 #define MIN_SLEEP_AVG		(HZ)
 #define MAX_SLEEP_AVG		(10*HZ)
 #define STARVATION_LIMIT	(10*HZ)
-#define SLEEP_BUFFER		(HZ/20)
 #define NODE_THRESHOLD		125
 #define MAX_BONUS		((MAX_USER_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100)
+#define ISO_PENALTY		(5)
 
 /*
  * If a task is 'interactive' then we reinsert it in the active
@@ -118,6 +118,8 @@
 #define TASK_INTERACTIVE(p) \
 	((p)->prio <= (p)->static_prio - DELTA(p))
 
+#define iso_task(p)		((p)->policy == SCHED_ISO)
+
 /*
  * BASE_TIMESLICE scales user-nice values [ -20 ... 19 ]
  * to time slice values.
@@ -134,7 +136,16 @@
 
 static inline unsigned int task_timeslice(task_t *p)
 {
-	return BASE_TIMESLICE(p);
+	if (!iso_task(p))
+		return (BASE_TIMESLICE(p));
+	else {
+		int timeslice = BASE_TIMESLICE(p) / ISO_PENALTY;
+
+		if (timeslice < MIN_TIMESLICE)
+			timeslice = MIN_TIMESLICE;
+
+		return timeslice;
+	}
 }
 
 /*
@@ -319,6 +330,14 @@ static inline void normalise_sleep(task_
 
 	p->sleep_avg = p->sleep_avg * MIN_SLEEP_AVG / old_avg_time;
 	p->avg_start = jiffies - MIN_SLEEP_AVG;
+
+	/*
+	 * New children and their parents are not allowed to
+	 * be SCHED_ISO.
+	 */
+	if (iso_task(p))
+		p->policy = SCHED_NORMAL;
+
 }
 
 /*
@@ -343,26 +362,35 @@ static int effective_prio(task_t *p)
 	if (rt_task(p))
 		return p->prio;
 
-	sleep_period = jiffies - p->avg_start;
+	if (!iso_task(p)){
+		sleep_period = jiffies - p->avg_start;
 
-	if (unlikely(!sleep_period))
-		return p->static_prio;
+		if (unlikely(!sleep_period))
+			return p->static_prio;
 
-	if (sleep_period > MAX_SLEEP_AVG)
-		sleep_period = MAX_SLEEP_AVG;
+		if (sleep_period > MAX_SLEEP_AVG)
+			sleep_period = MAX_SLEEP_AVG;
 
-	if (p->sleep_avg > sleep_period)
-		sleep_period = p->sleep_avg;
+		if (p->sleep_avg > sleep_period)
+			sleep_period = p->sleep_avg;
 
-	/*
-	 * The bonus is determined according to the accumulated
-	 * sleep avg over the duration the task has been running
-	 * until it reaches MAX_SLEEP_AVG. -ck
-	 */
-	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100 -
-			MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
+		/*
+		 * The bonus is determined according to the accumulated
+		 * sleep avg over the duration the task has been running
+		 * until it reaches MAX_SLEEP_AVG. -ck
+		 */
+		bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100 -
+				MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
+
+	} else
+		/*
+		 * SCHED_ISO tasks get the maximum possible bonus
+		 */
+		bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO/100 -
+				MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
 
 	prio = p->static_prio - bonus;
+
 	if (prio < MAX_RT_PRIO)
 		prio = MAX_RT_PRIO;
 	if (prio > MAX_PRIO-1)
@@ -398,6 +426,11 @@ static inline void activate_task(task_t 
 		 * to allow them to become interactive or non-interactive rapidly
 		 */
 		if (sleep_time > MIN_SLEEP_AVG){
+			/*
+			 * Idle tasks can not be SCHED_ISO
+			 */
+			if (iso_task(p))
+				p->policy = SCHED_NORMAL;
 			p->avg_start = jiffies - MIN_SLEEP_AVG;
 			p->sleep_avg = MIN_SLEEP_AVG * (MAX_BONUS - INTERACTIVE_DELTA - 1) /
 				MAX_BONUS;
@@ -422,13 +455,24 @@ static inline void activate_task(task_t 
 					(MAX_SLEEP_AVG + MIN_SLEEP_AVG - runtime) *
 					(MAX_BONUS - INTERACTIVE_DELTA) / MAX_BONUS / MAX_SLEEP_AVG;
 
+			if (p->sleep_avg > MAX_SLEEP_AVG){
+				/*
+				 * Tasks that have slept more than MAX_SLEEP_AVG
+				 * become SCHED_ISO tasks.
+				 */
+				if (p->policy == SCHED_NORMAL)
+					p->policy = SCHED_ISO;
+				p->sleep_avg = MAX_SLEEP_AVG;
+			}
+
 			/*
-			 * Keep a small buffer of SLEEP_BUFFER sleep_avg to
-			 * prevent fully interactive tasks from becoming
-			 * lower priority with small bursts of cpu usage.
+			 * Just in case a SCHED_ISO task has become a complete
+			 * cpu hog revert it to SCHED_NORMAL
 			 */
-			if (p->sleep_avg > (MAX_SLEEP_AVG + SLEEP_BUFFER))
-				p->sleep_avg = MAX_SLEEP_AVG + SLEEP_BUFFER;
+			if (unlikely(!p->sleep_avg && iso_task(p))){
+				p->policy = SCHED_NORMAL;
+				p->avg_start = jiffies;
+			}
 		}
 
 		if (unlikely(p->avg_start > jiffies)){
@@ -1309,12 +1353,23 @@ void scheduler_tick(int user_ticks, int 
 		p->time_slice = task_timeslice(p);
 		p->first_time_slice = 0;
 
-		if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq)) {
+		/*
+		 * If SCHED_ISO tasks are using too much cpu time they
+		 * enter the expired array.
+		 */
+		if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq) ||
+		(iso_task(p) && jiffies - p->avg_start < p->time_slice * ISO_PENALTY)) {
 			if (!rq->expired_timestamp)
 				rq->expired_timestamp = jiffies;
 			enqueue_task(p, rq->expired);
 		} else
 			enqueue_task(p, rq->active);
+		/*
+		 * p->avg_start is the last time a SCHED_ISO task
+		 * ran out of timeslice
+		 */
+		if (iso_task(p))
+			p->avg_start = jiffies;
 	}
 out_unlock:
 	spin_unlock(&rq->lock);
@@ -1819,7 +1874,7 @@ static int setscheduler(pid_t pid, int p
 	else {
 		retval = -EINVAL;
 		if (policy != SCHED_FIFO && policy != SCHED_RR &&
-				policy != SCHED_NORMAL)
+				policy != SCHED_NORMAL && policy != SCHED_ISO)
 			goto out_unlock;
 	}
 
@@ -1830,7 +1885,7 @@ static int setscheduler(pid_t pid, int p
 	retval = -EINVAL;
 	if (lp.sched_priority < 0 || lp.sched_priority > MAX_USER_RT_PRIO-1)
 		goto out_unlock;
-	if ((policy == SCHED_NORMAL) != (lp.sched_priority == 0))
+	if ((policy == SCHED_NORMAL || policy == SCHED_ISO) != (lp.sched_priority == 0))
 		goto out_unlock;
 
 	retval = -EPERM;
@@ -1852,7 +1907,7 @@ static int setscheduler(pid_t pid, int p
 	p->policy = policy;
 	p->rt_priority = lp.sched_priority;
 	oldprio = p->prio;
-	if (policy != SCHED_NORMAL)
+	if (policy == SCHED_FIFO || policy == SCHED_RR)
 		p->prio = MAX_USER_RT_PRIO-1 - p->rt_priority;
 	else
 		p->prio = p->static_prio;
@@ -2153,6 +2208,9 @@ asmlinkage long sys_sched_get_priority_m
 	case SCHED_NORMAL:
 		ret = 0;
 		break;
+	case SCHED_ISO:
+		ret = 0;
+		break;
 	}
 	return ret;
 }
@@ -2175,6 +2233,8 @@ asmlinkage long sys_sched_get_priority_m
 		break;
 	case SCHED_NORMAL:
 		ret = 0;
+	case SCHED_ISO:
+		ret = 0;
 	}
 	return ret;
 }

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

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

On Sat, 12 Jul 2003 09:37, Christian Axelsson wrote:
> On Fri, 2003-07-11 at 16:30, Con Kolivas wrote:
> > On Fri, 11 Jul 2003 22:48, Christian Axelsson wrote:
> > > Ok complies and boot fine
> > >
> > > BUT... after loading X up and gnome-theme-manager I start clicking
> > > around abit.. then gnome-theme-manager starts eating 99.9% CPU (prolly
> > > a bug in the program). Problem here is that the machine stops
> > > responding to input, at first I can move mouse around (but Im stuck in
> > > the current focused X-client) and later it all stalls... Cant even get
> > > in via SSH. Ive put on a top before repeating this showing
> > > gnome-theme-manager eating all CPU-time (PRI 15/NICE 0) and load
> > > showing ~55% user ~45% system.
> > >
> > > Anything I can do to help debugging?
> >
> > Can you try this patch instead which should stop the machine from getting
> > into a deadlock? I dont think I have found the problem but at least it
> > should be easier to diagnose without the machine locking up.
>
> Deadlock is gone but problem is still there.
> Running processes (state R) keep running smooth until they try to access
> any resource (ie. xmms keeps playing the current file but gets stuck
> when trying to open next one, top keeps running with full
> interactivity). Spawning new processes is impossible.
> I had top running over SSH and when I exited I managed to type 1 char
> then it hung up. A note is that sometimes the load is ~45% user ~55%
> system instead of ~55% user and ~45% system. There are always those
> values.
> I tried to reproduce by creating a while(1){} loop but it runs smooth.
>
> Any suggestions on methods to debug this?

Difficult apart from what you're already describing. The interesting point is 
the waiting for something that makes it hang, which reminds me of the 
parent-child waiting problem and is likely to be similar. The thing about iso 
tasks is they are by definition always active so they always get reinserted 
into the active array. However if they are waiting for something and are 
constantly preempting that something it will never happen. Can you try the 
attached diff which always puts them on the expired array if they run out of 
timeslice to see if that helps? This is not the ideal fix, but I need to see 
if it is the problem.

Con

[-- Attachment #2: patch-SIfix --]
[-- Type: text/x-diff, Size: 582 bytes --]

diff -Naurp linux-2.5.75-mm1/kernel/sched.c linux-2.5.75-test/kernel/sched.c
--- linux-2.5.75-mm1/kernel/sched.c	2003-07-12 10:04:21.000000000 +1000
+++ linux-2.5.75-test/kernel/sched.c	2003-07-12 10:05:34.000000000 +1000
@@ -1333,7 +1333,7 @@ void scheduler_tick(int user_ticks, int 
 		p->time_slice = task_timeslice(p);
 		p->first_time_slice = 0;
 
-		if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq)) {
+		if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq) || iso_task(p)) {
 			if (!rq->expired_timestamp)
 				rq->expired_timestamp = jiffies;
 			enqueue_task(p, rq->expired);

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Christian Axelsson]

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

On Fri, 2003-07-11 at 16:30, Con Kolivas wrote:
> On Fri, 11 Jul 2003 22:48, Christian Axelsson wrote:
> > Ok complies and boot fine
> >
> > BUT... after loading X up and gnome-theme-manager I start clicking around
> > abit.. then gnome-theme-manager starts eating 99.9% CPU (prolly a bug in
> > the program). Problem here is that the machine stops responding to input,
> > at first I can move mouse around (but Im stuck in the current focused
> > X-client) and later it all stalls... Cant even get in via SSH.
> > Ive put on a top before repeating this showing gnome-theme-manager eating
> > all CPU-time (PRI 15/NICE 0) and load showing ~55% user ~45% system.
> >
> > Anything I can do to help debugging?
> 
> Can you try this patch instead which should stop the machine from getting into 
> a deadlock? I dont think I have found the problem but at least it should be 
> easier to diagnose without the machine locking up.

Deadlock is gone but problem is still there.
Running processes (state R) keep running smooth until they try to access
any resource (ie. xmms keeps playing the current file but gets stuck
when trying to open next one, top keeps running with full
interactivity). Spawning new processes is impossible.
I had top running over SSH and when I exited I managed to type 1 char
then it hung up. A note is that sometimes the load is ~45% user ~55%
system instead of ~55% user and ~45% system. There are always those
values.
I tried to reproduce by creating a while(1){} loop but it runs smooth.

Any suggestions on methods to debug this?

-- 
Christian Axelsson
smiler@lanil.mine.nu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

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

On Fri, 11 Jul 2003 22:48, Christian Axelsson wrote:
> Ok complies and boot fine
>
> BUT... after loading X up and gnome-theme-manager I start clicking around
> abit.. then gnome-theme-manager starts eating 99.9% CPU (prolly a bug in
> the program). Problem here is that the machine stops responding to input,
> at first I can move mouse around (but Im stuck in the current focused
> X-client) and later it all stalls... Cant even get in via SSH.
> Ive put on a top before repeating this showing gnome-theme-manager eating
> all CPU-time (PRI 15/NICE 0) and load showing ~55% user ~45% system.
>
> Anything I can do to help debugging?

Can you try this patch instead which should stop the machine from getting into 
a deadlock? I dont think I have found the problem but at least it should be 
easier to diagnose without the machine locking up.

Con

[-- Attachment #2: patch-SI-0307120014 --]
[-- Type: text/x-diff, Size: 6107 bytes --]

diff -Naurp linux-2.5.75-mm1/include/linux/sched.h linux-2.5.75-test/include/linux/sched.h
--- linux-2.5.75-mm1/include/linux/sched.h	2003-07-12 00:03:51.000000000 +1000
+++ linux-2.5.75-test/include/linux/sched.h	2003-07-12 00:05:00.000000000 +1000
@@ -125,6 +125,7 @@ extern unsigned long nr_iowait(void);
 #define SCHED_NORMAL		0
 #define SCHED_FIFO		1
 #define SCHED_RR		2
+#define SCHED_ISO		3
 
 struct sched_param {
 	int sched_priority;
diff -Naurp linux-2.5.75-mm1/kernel/exit.c linux-2.5.75-test/kernel/exit.c
--- linux-2.5.75-mm1/kernel/exit.c	2003-07-12 00:01:38.000000000 +1000
+++ linux-2.5.75-test/kernel/exit.c	2003-07-12 00:05:00.000000000 +1000
@@ -223,7 +223,7 @@ void reparent_to_init(void)
 	/* Set the exit signal to SIGCHLD so we signal init on exit */
 	current->exit_signal = SIGCHLD;
 
-	if ((current->policy == SCHED_NORMAL) && (task_nice(current) < 0))
+	if ((current->policy == SCHED_NORMAL || current->policy == SCHED_ISO) && (task_nice(current) < 0))
 		set_user_nice(current, 0);
 	/* cpus_allowed? */
 	/* rt_priority? */
diff -Naurp linux-2.5.75-mm1/kernel/sched.c linux-2.5.75-test/kernel/sched.c
--- linux-2.5.75-mm1/kernel/sched.c	2003-07-12 00:03:51.000000000 +1000
+++ linux-2.5.75-test/kernel/sched.c	2003-07-12 00:13:21.000000000 +1000
@@ -76,9 +76,9 @@
 #define MIN_SLEEP_AVG		(HZ)
 #define MAX_SLEEP_AVG		(10*HZ)
 #define STARVATION_LIMIT	(10*HZ)
-#define SLEEP_BUFFER		(HZ/20)
 #define NODE_THRESHOLD		125
 #define MAX_BONUS		((MAX_USER_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100)
+#define ISO_PENALTY		(5)
 
 /*
  * If a task is 'interactive' then we reinsert it in the active
@@ -118,6 +118,8 @@
 #define TASK_INTERACTIVE(p) \
 	((p)->prio <= (p)->static_prio - DELTA(p))
 
+#define iso_task(p)		((p)->policy == SCHED_ISO)
+
 /*
  * BASE_TIMESLICE scales user-nice values [ -20 ... 19 ]
  * to time slice values.
@@ -134,7 +136,16 @@
 
 static inline unsigned int task_timeslice(task_t *p)
 {
-	return BASE_TIMESLICE(p);
+	if (!iso_task(p))
+		return (BASE_TIMESLICE(p));
+	else {
+		int timeslice = BASE_TIMESLICE(p) / ISO_PENALTY;
+
+		if (timeslice < MIN_TIMESLICE)
+			timeslice = MIN_TIMESLICE;
+
+		return timeslice;
+	}
 }
 
 /*
@@ -319,6 +330,10 @@ static inline void normalise_sleep(task_
 
 	p->sleep_avg = p->sleep_avg * MIN_SLEEP_AVG / old_avg_time;
 	p->avg_start = jiffies - MIN_SLEEP_AVG;
+
+	if (iso_task(p))
+		p->policy = SCHED_NORMAL;
+
 }
 
 /*
@@ -343,26 +358,32 @@ static int effective_prio(task_t *p)
 	if (rt_task(p))
 		return p->prio;
 
-	sleep_period = jiffies - p->avg_start;
+	if (!iso_task(p)){
+		sleep_period = jiffies - p->avg_start;
 
-	if (unlikely(!sleep_period))
-		return p->static_prio;
+		if (unlikely(!sleep_period))
+			return p->static_prio;
 
-	if (sleep_period > MAX_SLEEP_AVG)
-		sleep_period = MAX_SLEEP_AVG;
+		if (sleep_period > MAX_SLEEP_AVG)
+			sleep_period = MAX_SLEEP_AVG;
 
-	if (p->sleep_avg > sleep_period)
-		sleep_period = p->sleep_avg;
+		if (p->sleep_avg > sleep_period)
+			sleep_period = p->sleep_avg;
 
-	/*
-	 * The bonus is determined according to the accumulated
-	 * sleep avg over the duration the task has been running
-	 * until it reaches MAX_SLEEP_AVG. -ck
-	 */
-	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100 -
-			MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
+		/*
+		 * The bonus is determined according to the accumulated
+		 * sleep avg over the duration the task has been running
+		 * until it reaches MAX_SLEEP_AVG. -ck
+		 */
+		bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100 -
+				MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
+
+	} else
+		bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO/100 -
+				MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
 
 	prio = p->static_prio - bonus;
+
 	if (prio < MAX_RT_PRIO)
 		prio = MAX_RT_PRIO;
 	if (prio > MAX_PRIO-1)
@@ -401,6 +422,8 @@ static inline void activate_task(task_t 
 			p->avg_start = jiffies - MIN_SLEEP_AVG;
 			p->sleep_avg = MIN_SLEEP_AVG * (MAX_BONUS - INTERACTIVE_DELTA - 1) /
 				MAX_BONUS;
+			if (iso_task(p))
+				p->policy = SCHED_NORMAL;
 		} else {
 			/*
 			 * This code gives a bonus to interactive tasks.
@@ -422,13 +445,14 @@ static inline void activate_task(task_t 
 					(MAX_SLEEP_AVG + MIN_SLEEP_AVG - runtime) *
 					(MAX_BONUS - INTERACTIVE_DELTA) / MAX_BONUS / MAX_SLEEP_AVG;
 
-			/*
-			 * Keep a small buffer of SLEEP_BUFFER sleep_avg to
-			 * prevent fully interactive tasks from becoming
-			 * lower priority with small bursts of cpu usage.
-			 */
-			if (p->sleep_avg > (MAX_SLEEP_AVG + SLEEP_BUFFER))
-				p->sleep_avg = MAX_SLEEP_AVG + SLEEP_BUFFER;
+			if (p->sleep_avg > MAX_SLEEP_AVG){
+				if (p->policy == SCHED_NORMAL)
+					p->policy = SCHED_ISO;
+				p->sleep_avg = MAX_SLEEP_AVG;
+			}
+
+			if (unlikely(!p->sleep_avg && iso_task(p)))
+				p->policy = SCHED_NORMAL;
 		}
 
 		if (unlikely(p->avg_start > jiffies)){
@@ -1819,7 +1843,7 @@ static int setscheduler(pid_t pid, int p
 	else {
 		retval = -EINVAL;
 		if (policy != SCHED_FIFO && policy != SCHED_RR &&
-				policy != SCHED_NORMAL)
+				policy != SCHED_NORMAL && policy != SCHED_ISO)
 			goto out_unlock;
 	}
 
@@ -1830,7 +1854,7 @@ static int setscheduler(pid_t pid, int p
 	retval = -EINVAL;
 	if (lp.sched_priority < 0 || lp.sched_priority > MAX_USER_RT_PRIO-1)
 		goto out_unlock;
-	if ((policy == SCHED_NORMAL) != (lp.sched_priority == 0))
+	if ((policy == SCHED_NORMAL || policy == SCHED_ISO) != (lp.sched_priority == 0))
 		goto out_unlock;
 
 	retval = -EPERM;
@@ -1852,7 +1876,7 @@ static int setscheduler(pid_t pid, int p
 	p->policy = policy;
 	p->rt_priority = lp.sched_priority;
 	oldprio = p->prio;
-	if (policy != SCHED_NORMAL)
+	if (policy == SCHED_FIFO || policy == SCHED_RR)
 		p->prio = MAX_USER_RT_PRIO-1 - p->rt_priority;
 	else
 		p->prio = p->static_prio;
@@ -2153,6 +2177,9 @@ asmlinkage long sys_sched_get_priority_m
 	case SCHED_NORMAL:
 		ret = 0;
 		break;
+	case SCHED_ISO:
+		ret = 0;
+		break;
 	}
 	return ret;
 }
@@ -2175,6 +2202,8 @@ asmlinkage long sys_sched_get_priority_m
 		break;
 	case SCHED_NORMAL:
 		ret = 0;
+	case SCHED_ISO:
+		ret = 0;
 	}
 	return ret;
 }

[RFC][PATCH] SCHED_ISO for interactivity

[Con Kolivas]

[-- Attachment #1: clearsigned data --]
[-- Type: Text/Plain, Size: 1993 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After the recent discussions about the limitations on real time tasks and 
normal users...

Wli coined the term "isochronous" (greek for same time) for a real time task 
that was limited in it's timeslice but still guaranteed to run. I've decided 
to abuse this term and use it to name this new policy in this patch. This is 
neither real time, nor guaranteed.

What this patch does is introduce a new scheduler policy, SCHED_ISO. SI tasks 
get the maximum interactive bonus so they always get a dynamic priority of 5 
better than their static priority, but are penalised by having a smaller 
timeslice. Most interactive tasks don't use up their full timeslice anyway.

Since most users and applications are not going to be altering scheduler 
policies, this patch uses the current semantics in patches up to the O4int 
patch I have posted previously (and in 2.5.75-mm1) to dynamically allocate 
tasks as SI. This happens when their sleep avg hits MAX_SLEEP_AVG which is 
extremely unlikely to happen for the wrong task. Unfortunately it also means 
it takes at least 10 seconds. There are semantics in place to stop it 
happening to idle tasks, tasks forking, and new children.

Anyway it's pretty rough around the edges since I slapped it together more to 
prove it works, but appears to work as planned. The O*int patches appear to 
be hitting a ceiling to their ability and this can help them further but I 
need some feedback about it's usefulness, and appropriateness. 

Without further feedback about the O*int patches I can't do much to develop 
them further.

akpm: obviously this one is not to be included in -mm 

Enough talk. The patch is attached below and available at:
http://kernel.kolivas.org/2.5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/DpcyF6dfvkL3i1gRAjp9AJ9S30i7ZQjpM7ETsxchKuLnDaL8GgCfb9OU
xl8PGFqY5BXEWPs83OaUCLY=
=cUdC
-----END PGP SIGNATURE-----

[-- Attachment #2: patch-SI-0307111938 --]
[-- Type: text/x-diff, Size: 5578 bytes --]

--- linux-2.5.74-mm3/include/linux/sched.h	2003-07-10 10:23:14.000000000 +1000
+++ linux-2.5.74-test/include/linux/sched.h	2003-07-11 19:35:37.000000000 +1000
@@ -125,6 +125,7 @@ extern unsigned long nr_iowait(void);
 #define SCHED_NORMAL		0
 #define SCHED_FIFO		1
 #define SCHED_RR		2
+#define SCHED_ISO		3
 
 struct sched_param {
 	int sched_priority;
--- linux-2.5.74-mm3/kernel/exit.c	2003-07-10 10:23:14.000000000 +1000
+++ linux-2.5.74-test/kernel/exit.c	2003-07-11 19:35:37.000000000 +1000
@@ -223,7 +223,7 @@ void reparent_to_init(void)
 	/* Set the exit signal to SIGCHLD so we signal init on exit */
 	current->exit_signal = SIGCHLD;
 
-	if ((current->policy == SCHED_NORMAL) && (task_nice(current) < 0))
+	if ((current->policy == SCHED_NORMAL || current->policy == SCHED_ISO) && (task_nice(current) < 0))
 		set_user_nice(current, 0);
 	/* cpus_allowed? */
 	/* rt_priority? */
--- linux-2.5.74-mm3/kernel/sched.c	2003-07-11 19:43:34.000000000 +1000
+++ linux-2.5.74-test/kernel/sched.c	2003-07-11 19:38:09.000000000 +1000
@@ -76,7 +76,6 @@
 #define MIN_SLEEP_AVG		(HZ)
 #define MAX_SLEEP_AVG		(10*HZ)
 #define STARVATION_LIMIT	(10*HZ)
-#define SLEEP_BUFFER		(HZ/20)
 #define NODE_THRESHOLD		125
 #define MAX_BONUS		((MAX_USER_PRIO - MAX_RT_PRIO) * PRIO_BONUS_RATIO / 100)
 
@@ -118,6 +117,8 @@
 #define TASK_INTERACTIVE(p) \
 	((p)->prio <= (p)->static_prio - DELTA(p))
 
+#define iso_task(p)		((p)->policy == SCHED_ISO)
+
 /*
  * BASE_TIMESLICE scales user-nice values [ -20 ... 19 ]
  * to time slice values.
@@ -134,7 +135,10 @@
 
 static inline unsigned int task_timeslice(task_t *p)
 {
-	return BASE_TIMESLICE(p);
+	if (iso_task(p))
+		return (BASE_TIMESLICE(p) / 5 ? : 1);
+	else
+		return BASE_TIMESLICE(p);
 }
 
 /*
@@ -319,6 +323,10 @@ static inline void normalise_sleep(task_
 
 	p->sleep_avg = p->sleep_avg * MIN_SLEEP_AVG / old_avg_time;
 	p->avg_start = jiffies - MIN_SLEEP_AVG;
+
+	if (iso_task(p))
+		p->policy = SCHED_NORMAL;
+
 }
 
 /*
@@ -343,26 +351,32 @@ static int effective_prio(task_t *p)
 	if (rt_task(p))
 		return p->prio;
 
-	sleep_period = jiffies - p->avg_start;
+	if (!iso_task(p)){
+		sleep_period = jiffies - p->avg_start;
 
-	if (unlikely(!sleep_period))
-		return p->static_prio;
+		if (unlikely(!sleep_period))
+			return p->static_prio;
 
-	if (sleep_period > MAX_SLEEP_AVG)
-		sleep_period = MAX_SLEEP_AVG;
+		if (sleep_period > MAX_SLEEP_AVG)
+			sleep_period = MAX_SLEEP_AVG;
 
-	if (p->sleep_avg > sleep_period)
-		sleep_period = p->sleep_avg;
+		if (p->sleep_avg > sleep_period)
+			sleep_period = p->sleep_avg;
 
-	/*
-	 * The bonus is determined according to the accumulated
-	 * sleep avg over the duration the task has been running
-	 * until it reaches MAX_SLEEP_AVG. -ck
-	 */
-	bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100 -
-			MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
+		/*
+		 * The bonus is determined according to the accumulated
+		 * sleep avg over the duration the task has been running
+		 * until it reaches MAX_SLEEP_AVG. -ck
+		 */
+		bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/sleep_period/100 -
+				MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
+
+	} else
+		bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO/100 -
+				MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
 
 	prio = p->static_prio - bonus;
+
 	if (prio < MAX_RT_PRIO)
 		prio = MAX_RT_PRIO;
 	if (prio > MAX_PRIO-1)
@@ -401,6 +415,8 @@ static inline void activate_task(task_t 
 			p->avg_start = jiffies - MIN_SLEEP_AVG;
 			p->sleep_avg = MIN_SLEEP_AVG * (MAX_BONUS - INTERACTIVE_DELTA - 1) /
 				MAX_BONUS;
+			if (iso_task(p))
+				p->policy = SCHED_NORMAL;
 		} else {
 			/*
 			 * This code gives a bonus to interactive tasks.
@@ -422,13 +438,11 @@ static inline void activate_task(task_t 
 					(MAX_SLEEP_AVG + MIN_SLEEP_AVG - runtime) *
 					(MAX_BONUS - INTERACTIVE_DELTA) / MAX_BONUS / MAX_SLEEP_AVG;
 
-			/*
-			 * Keep a small buffer of SLEEP_BUFFER sleep_avg to
-			 * prevent fully interactive tasks from becoming
-			 * lower priority with small bursts of cpu usage.
-			 */
-			if (p->sleep_avg > (MAX_SLEEP_AVG + SLEEP_BUFFER))
-				p->sleep_avg = MAX_SLEEP_AVG + SLEEP_BUFFER;
+			if (p->sleep_avg > MAX_SLEEP_AVG){
+				if (p->policy == SCHED_NORMAL)
+					p->policy = SCHED_ISO;
+				p->sleep_avg = MAX_SLEEP_AVG;
+			}
 		}
 
 		if (unlikely(p->avg_start > jiffies)){
@@ -1813,7 +1827,7 @@ static int setscheduler(pid_t pid, int p
 	else {
 		retval = -EINVAL;
 		if (policy != SCHED_FIFO && policy != SCHED_RR &&
-				policy != SCHED_NORMAL)
+				policy != SCHED_NORMAL && policy != SCHED_ISO)
 			goto out_unlock;
 	}
 
@@ -1824,7 +1838,7 @@ static int setscheduler(pid_t pid, int p
 	retval = -EINVAL;
 	if (lp.sched_priority < 0 || lp.sched_priority > MAX_USER_RT_PRIO-1)
 		goto out_unlock;
-	if ((policy == SCHED_NORMAL) != (lp.sched_priority == 0))
+	if ((policy == SCHED_NORMAL || policy == SCHED_ISO) != (lp.sched_priority == 0))
 		goto out_unlock;
 
 	retval = -EPERM;
@@ -1846,7 +1860,7 @@ static int setscheduler(pid_t pid, int p
 	p->policy = policy;
 	p->rt_priority = lp.sched_priority;
 	oldprio = p->prio;
-	if (policy != SCHED_NORMAL)
+	if (policy == SCHED_FIFO || policy == SCHED_RR)
 		p->prio = MAX_USER_RT_PRIO-1 - p->rt_priority;
 	else
 		p->prio = p->static_prio;
@@ -2147,6 +2161,9 @@ asmlinkage long sys_sched_get_priority_m
 	case SCHED_NORMAL:
 		ret = 0;
 		break;
+	case SCHED_ISO:
+		ret = 0;
+		break;
 	}
 	return ret;
 }
@@ -2169,6 +2186,8 @@ asmlinkage long sys_sched_get_priority_m
 		break;
 	case SCHED_NORMAL:
 		ret = 0;
+	case SCHED_ISO:
+		ret = 0;
 	}
 	return ret;
 }