SCHED_ISO for interactivity
RFC PATCH 1/1 SCHED_ISO for interactivity
-----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-----
include/linux/sched.h +1 -0
@@ -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 3struct sched_param {int sched_priority;
kernel/exit.c +1 -1
@@ -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? */
kernel/sched.c +45 -26
149 lines not on this page · raw message
A message that is not in the archive (sent off-list or not yet received): 1068.::ffff:[email protected]
Quoted 11 lines · Christian Axelsson
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
include/linux/sched.h +1 -0
@@ -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 3struct sched_param {int sched_priority;
kernel/exit.c +1 -1
@@ -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? */
kernel/sched.c +55 -26
161 lines not on this page · raw message
Quoted 11 lines · Con Kolivas
Quoted 10 lines · Christian Axelsson
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.
Quoted 5 lines
Quoted 1 line
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?
Signature · 2 lines
Christian Axelsson [email protected]
Quoted 30 lines · Christian Axelsson
Quoted 12 lines · Con Kolivas
Quoted 11 lines · Christian Axelsson
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.
Quoted 5 lines
Quoted 1 line
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.
Quoted 1 line
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
kernel/sched.c +1 -1
@@ -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);
Quoted 3 lines · Con Kolivas
Quoted 2 lines · Christian Axelsson
Quoted 1 line · Con Kolivas
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
include/linux/sched.h +1 -0
@@ -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 3struct sched_param {int sched_priority;
kernel/exit.c +1 -1
@@ -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? */
kernel/sched.c +85 -25
203 lines not on this page · raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 12 July 2003 17:39, Con Kolivas wrote:
[SNIP]
Quoted 11 lines
kernel/sched.c +3
-0@@ -2153,6 +2208,9 @@ asmlinkage long sys_sched_get_priority_mcase SCHED_NORMAL : ret =0 ;break ; +case SCHED_ISO : + ret =0 ; +break ; }return ret; }
kernel/sched.c asmlinkage long sys_sched_get_priority_m · line 2240
Quoted 8 lines
kernel/sched.c +2
-0@@ -2175,6 +2233,8 @@ asmlinkage long sys_sched_get_priority_mbreak ;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-----
Quoted 4 lines · Con Kolivas
Quoted 3 lines · Con Kolivas
Quoted 2 lines · Christian Axelsson
Quoted 1 line · Con Kolivas
On Fri, 11 Jul 2003 22:48, Christian Axelsson wrote:
Quoted 8 lines
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).
Signature · 2 lines
Christian Axelsson [email protected]
Quoted 12 lines · Christian Axelsson
Quoted 11 lines · Con Kolivas
Quoted 3 lines · Con Kolivas
Quoted 2 lines · Christian Axelsson
Quoted 1 line · Con Kolivas
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.
Quoted 5 lines
Quoted 2 lines
patch-SI-0307130021 is also available at
http://kernel.kolivas.org/2.5Problem 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
Quoted 19 lines · Con Kolivas
Quoted 12 lines · Christian Axelsson
Quoted 11 lines · Con Kolivas
Quoted 3 lines · Con Kolivas
Quoted 2 lines · Christian Axelsson
Quoted 1 line · Con Kolivas
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.
Quoted 5 lines
Quoted 2 lines
patch-SI-0307130021 is also available at
http://kernel.kolivas.org/2.5Problem seems to be gone (cant be 100% sure as I aint really sure WHAT trigged this behavior).
Quoted 6 lines
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.
Signature · 2 lines
Christian Axelsson [email protected]
Quoted 2 lines · Con Kolivas
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
Quoted 4 lines · Con Kolivas
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
Quoted 7 lines · William Lee Irwin III
Quoted 4 lines · Con Kolivas
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
Quoted 7 lines · William Lee Irwin III
Quoted 4 lines · Con Kolivas
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
Quoted 7 lines · Daniel Phillips
Quoted 6 lines · William Lee Irwin III
Quoted 4 lines · Con Kolivas
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.
Quoted 8 lines
Quoted 1 line
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
Quoted 3 lines · Con Kolivas
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.
Quoted 2 lines
which gives no more capabilities to a normal user process than they can currently get on
SCHED_NORMALtasks. 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.
Quoted 2 lines
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