-----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-----
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
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
[email protected]
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
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;
}
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
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
-----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-----
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
[email protected]
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
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
[email protected]
On Mon, 14 Jul 2003 00:54, Guillaume Chazarain wrote:
> 13/07/03 14:53:12, Con Kolivas <[email protected]> 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
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
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
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
13/07/03 14:53:12, Con Kolivas <[email protected]> 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
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
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
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
[email protected]
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
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
On Mon, 14 Jul 2003 00:54, Guillaume Chazarain wrote:
> 13/07/03 14:53:12, Con Kolivas <[email protected]> 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;
14/07/03 02:07:34, Con Kolivas <[email protected]> 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
On Tue, 15 Jul 2003 01:40, Guillaume Chazarain wrote:
> 14/07/03 02:07:34, Con Kolivas <[email protected]> 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