Nick's scheduler policy v12
Subsystems (4)
PATCH 1/1 Nick's scheduler policy v12
Hi,
Backboost is gone so X really should be at -10 or even higher. I'm now using 160 bits of the priority array instead of 140. This works on x86, but I haven't had a look at other architectures.
Its still sort of in progress, but I thought I should send an update. Its against 2.6.0-test4 and includes my other assorted scheduler patches.
Scheduling latency is very good now, < 50ms for a nice 0 process doing nothing except a signal once in a while. This during a make -j3 compile and mad X activity on UP.
I still need to think about how to get X working a bit more nicely though. I'd like to be able to get good interactivity with large make loads, but thats at the bottom of the list.
linux-2.6-npiggin/fs/proc/array.c | 7 linux-2.6-npiggin/include/linux/sched.h | 10 linux-2.6-npiggin/kernel/fork.c | 30 - linux-2.6-npiggin/kernel/sched.c | 542 +++++++++++++++++++------------- 4 files changed, 342 insertions(+), 247 deletions(-)
fs/proc/array.c renamed from fs/proc/array.c~rollup +6 -1
@@ -154,13 +154,18 @@ static inline char * task_state(struct tread_lock (&tasklist_lock); buffer += sprintf(buffer, "State:\t%s\n" + "sleep_avg:\t%lu\n" + "sleep_time:\t%lu\n" + "total_time:\t%lu\n" "Tgid:\t%d\n" "Pid:\t%d\n" "PPid:\t%d\n" "TracerPid:\t%d\n" "Uid:\t%d\t%d\t%d\t%d\n" "Gid:\t%d\t%d\t%d\t%d\n", - get_task_state(p), p->tgid, + get_task_state(p), + p->sleep_avg, p->sleep_time, p->total_time, + p->tgid, p->pid, p->pid ? p->real_parent->pid : 0, p->pid && p->ptrace ? p->parent->pid : 0, p->uid, p->euid, p->suid, p->fsuid,
include/linux/sched.h renamed from include/linux/sched.h~rollup +8 -2
@@ -280,7 +280,7 @@ struct signal_struct {#define MAX_USER_RT_PRIO 100#define MAX_RT_PRIO MAX_USER_RT_PRIO -#define MAX_PRIO (MAX_RT_PRIO + 40) +#define MAX_PRIO (MAX_RT_PRIO + 60)/* * Some day this will be a full-fledged user tracking system..
@@ -339,12 +339,17 @@ struct task_struct {struct list_head run_list;prio_array_t *array; +/* Scheduler variables follow. kernel/sched.c */ +unsigned long array_sequence; +unsigned long timestamp; + +unsigned long total_time, sleep_time;unsigned long sleep_avg; -unsigned long last_run;unsigned long policy;cpumask_t cpus_allowed;unsigned int time_slice, first_time_slice; +unsigned int used_slice;struct list_head tasks;struct list_head ptrace_children;
@@ -552,6 +557,7 @@ extern int FASTCALL(wake_up_state(structextern int FASTCALL (wake_up_process (struct task_struct * tsk));extern int FASTCALL (wake_up_process_kick (struct task_struct * tsk));extern void FASTCALL (wake_up_forked_process (struct task_struct * tsk)); +extern void FASTCALL (sched_fork (task_t * p));extern void FASTCALL (sched_exit (task_t * p));asmlinkage long sys_wait4 (pid_t pid,unsigned int * stat_addr,int options,struct rusage * ru);
kernel/fork.c renamed from kernel/fork.c~rollup +3 -27
@@ -911,33 +911,9 @@ struct task_struct *copy_process(unsigne p->exit_signal = (clone_flags &CLONE_THREAD ) ?-1 : (clone_flags &CSIGNAL ); p->pdeath_signal =0 ; -/* -* Share the timeslice between parent and child, thus the -* total amount of pending timeslices in the system doesn't change, -* resulting in more scheduling fairness. -*/ -local_irq_disable (); - p->time_slice = (current->time_slice +1 ) >>1 ; -/* -* The remainder of the first timeslice might be recovered by -* the parent if the child exits early enough. -*/ - p->first_time_slice =1 ; - current->time_slice >>=1 ; - p->last_run = jiffies; -if (!current->time_slice) { -/* -* This case is rare, it happens when the parent has only -* a single jiffy left from its timeslice. Taking the -* runqueue lock is not a problem. -*/ - current->time_slice =1 ; -preempt_disable (); -scheduler_tick (0 ,0 ); -local_irq_enable (); -preempt_enable (); - }else -local_irq_enable (); +/* Perform scheduler related accounting */ +sched_fork (p); +/* * Ok, add it to the run-queues and make it * visible to the rest of the system.
kernel/sched.c renamed from kernel/sched.c~rollup +325 -217
786 lines not on this page · raw message
_
Quoted 1 line
Backboost is gone so X really should be at -10 or even higher.
Wasn't that causing half the problems originally? Boosting X seemed to starve xmms et al. Or do the interactivity changes fix xmms somehow, but not X itself? Explicitly fiddling with task's priorities seems flawed to me.
M.
Quoted 6 lines · Martin J. Bligh
Quoted 1 line
Backboost is gone so X really should be at -10 or even higher.
Wasn't that causing half the problems originally? Boosting X seemed to starve xmms et al. Or do the interactivity changes fix xmms somehow, but not X itself? Explicitly fiddling with task's priorities seems flawed to me.
Wasn't it the larger timeslices with lower nice values in stock and Con's patches that made X with nice -10 a bad idea?
Quoted 10 lines · Martin J. Bligh
Quoted 6 lines
Quoted 1 line
Backboost is gone so X really should be at -10 or even higher.
Wasn't that causing half the problems originally? Boosting X seemed to starve xmms et al. Or do the interactivity changes fix xmms somehow, but not X itself? Explicitly fiddling with task's priorities seems flawed to me.
Wasn't it the larger timeslices with lower nice values in stock and Con's patches that made X with nice -10 a bad idea?
Debian renices X by default to -10 ... I fixed all my desktop interactivity problems around 2.5.63 timeframe by just turning that off. That was way before Con's patches.
There may be some more details around this, and I'd love to hear them, but I fundmantally believe that explitit fiddling with particular processes because we believe they're somehow magic is wrong (and so does Linus, from previous discussions).
M.
Quoted 8 lines · Martin J. Bligh
Quoted 8 lines · Martin J. Bligh
Quoted 6 lines
Quoted 1 line
Backboost is gone so X really should be at -10 or even higher.
Wasn't that causing half the problems originally? Boosting X seemed to starve xmms et al. Or do the interactivity changes fix xmms somehow, but not X itself? Explicitly fiddling with task's priorities seems flawed to me.
Quoted 6 lines
Quoted 2 lines
Wasn't it the larger timeslices with lower nice values in stock and Con's patches that made X with nice -10 a bad idea?
Debian renices X by default to -10 ... I fixed all my desktop interactivity problems around 2.5.63 timeframe by just turning that off. That was way before Con's patches.
Exactly. Because the larger time slices for lower nice values came from O(1), not Con.
Quoted 6 lines
There may be some more details around this, and I'd love to hear them, but I fundmantally believe that explitit fiddling with particular processes because we believe they're somehow magic is wrong (and so does Linus, from previous discussions).
Linus added a patch to 2.5.65 or so that was supposed to allow nice 0 on X without any detrament.
Quoted 2 lines · Mike Fedyk
Exactly. Because the larger time slices for lower nice values came from O(1), not Con.
The larger timeslices may not help, but one reason why renicing X hurts multimedia is that it gives a preference to the GUI over the multimedia thread(s).
Look at it this way. Assume renicing X does not _help_ whatever the problem is (simply because the problem, in this case, is not stemming from X). Then giving X the higher priority and larger timeslice only adversely affects the problem.
So, since the multimedia thread in (say) xmms is really unrelated to X (its a separate thread and not doing any Xlib calls), it just hurts it.
Quoted 2 lines
Linus added a patch to 2.5.65 or so that was supposed to allow nice 0 on X without any detrament.
That is the backboost thing. It was ripped out, due to regressions in SETI and elsewhere.
Nick added a similar thing back in, but he just removed it. Its a shame it cannot be made to work, because I like the idea. I talked with Nick and OLS about the ability of a forward+back boost combination to solve our interactivity issues. I really wish they panned out.
Robert Love
Quoted 11 lines · Robert Love
Quoted 3 lines · Mike Fedyk
Exactly. Because the larger time slices for lower nice values came from O(1), not Con.
The larger timeslices may not help, but one reason why renicing X hurts multimedia is that it gives a preference to the GUI over the multimedia thread(s).
Quoted 8 lines
Look at it this way. Assume renicing X does not _help_ whatever the problem is (simply because the problem, in this case, is not stemming from X). Then giving X the higher priority and larger timeslice only adversely affects the problem.
So, since the multimedia thread in (say) xmms is really unrelated to X (its a separate thread and not doing any Xlib calls), it just hurts it.
Hi Robert,
Yeah you are right. Backboost is sort of an implicit renice though, except it doesn't always go where you want it or when you want :(
I have found that is enough to have good scheduling latency to ensure xmms skips are difficult to produce.
Quoted 9 lines · Martin J. Bligh
Quoted 9 lines · Martin J. Bligh
Quoted 8 lines
Quoted 3 lines
Backboost is gone so X really should be at -10 or even higher.
Wasn't that causing half the problems originally? Boosting X seemed to starve xmms et al. Or do the interactivity changes fix xmms somehow, but not X itself? Explicitly fiddling with task's priorities seems flawed to me.
Quoted 7 lines
Quoted 3 lines
Wasn't it the larger timeslices with lower nice values in stock and Con's patches that made X with nice -10 a bad idea?
Debian renices X by default to -10 ... I fixed all my desktop interactivity problems around 2.5.63 timeframe by just turning that off. That was way before Con's patches.
Yep, as Mike mentioned, renicing X causes it to get bigger timeslices with the stock scheduler. If you had 2 nice -20 processes, they would each get a timeslice of 200ms, so you're harming their latency.
Quoted 6 lines
There may be some more details around this, and I'd love to hear them, but I fundmantally believe that explitit fiddling with particular processes because we believe they're somehow magic is wrong (and so does Linus, from previous discussions).
Well it would be nice if someone could find out how to do it, but I think that if we want X to be able to get 80% CPU when 2 other CPU hogs are running, you have to renice it.
Quoted 4 lines
Yep, as Mike mentioned, renicing X causes it to get bigger timeslices with the stock scheduler. If you had 2 nice -20 processes, they would each get a timeslice of 200ms, so you're harming their latency.
Well, if I can be naive for a second (and I'll fully admit I don't understand the implications of this), there are two things here - either give it more of a timeslice (bandwidth increase), or make it more interactive (latency increase). Those two seem to be separable, but we don't bother. Seems better to pass a more subtle hint to the scheduler that this is interactive - nice seems like a very large brick between the eyes.
Quoted 8 lines
Quoted 4 lines
There may be some more details around this, and I'd love to hear them, but I fundmantally believe that explitit fiddling with particular processes because we believe they're somehow magic is wrong (and so does Linus, from previous discussions).
Well it would be nice if someone could find out how to do it, but I think that if we want X to be able to get 80% CPU when 2 other CPU hogs are running, you have to renice it.
OK. So you renice it ... then your two cpu jobs exit, and you kick off xmms. Every time you waggle a window, X will steal the cpu back from xmms, and it'll stall, surely? That's what seemed to happen before. I don't see how you can fix anything by doing static priority alterations (eg nice), because the workload changes.
I'm probably missing something ... feel free to slap me ;-)
M.
Quoted 8 lines · Martin J. Bligh
Well, if I can be naive for a second (and I'll fully admit I don't understand the implications of this), there are two things here - either give it more of a timeslice (bandwidth increase), or make it more interactive (latency increase). Those two seem to be separable, but we don't bother. Seems better to pass a more subtle hint to the scheduler that this is interactive - nice seems like a very large brick between the eyes.
Just as naïve as you, Martin, but your idea is at least incomplete. We have to make some processes behave differently, right, but we also have to detect, which ones they are. Is the user unhappy with gcc being a bit jerky? No, so gcc is not a problem. X, xmms, xine, mplayer, quake and a thousand more make the user unhappy, but how do we detect them and only them? And which ones do we favor if several are competing?
One way is to let the user tell you, through nice or anything else, but the user doesn't want to, so that is suboptimal.
Another way is to integrate the GUI into the kernel, so you know which window is on top, etc. But we surely don't want that.
A third way may be to accept hints from userspace, so that X can tell us, which window is on top. Maybe as a last resort.
What remains is to try to detect the "interactive" processes through their behaviour and I am not sure if it is possible to always get this right in the general case.
Detecting the right processes is the real problem, Martin. If you can do that, the rest is quite simple. And so far, we are quite bad at it. :(
Quoted 1 line
I'm probably missing something ... feel free to slap me ;-)
*slap*
Maybe you didn't offer me to, but it still felt good. :)
Jörn
Signature · 3 lines
Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
Quoted 6 lines · Martin J. Bligh
Quoted 5 lines
Yep, as Mike mentioned, renicing X causes it to get bigger timeslices with the stock scheduler. If you had 2 nice -20 processes, they would each get a timeslice of 200ms, so you're harming their latency.
Quoted 6 lines
Well, if I can be naive for a second (and I'll fully admit I don't
understand the implications of this), there are two things here - either give it more of a timeslice (bandwidth increase), or make it more interactive (latency increase). Those two seem to be separable, but we don't bother. Seems better to pass a more subtle hint to the
scheduler that this is interactive - nice seems like a very large
brick between the eyes.
I think the two will always related. One means giving a higher dynamic priority, the other a bigger timeslice. So you want say gcc to have a 100ms timeslice with lowest scheduling prio, but X to have a 20ms slice and a very high scheduling priority.
Unfortunately, the way the scheduler currently works, X might use all its timeslice, then have to wait 100ms for gcc to finish its. The way I do it is give a small timeslice to high prio tasks, and lower priority tasks get progressively less.
When _only_ low priority tasks are running, they'll all get long timeslices.
Quoted 11 lines
Quoted 10 lines
Quoted 6 lines
There may be some more details around this, and I'd love to hear them, but I fundmantally believe that explitit fiddling with particular processes because we believe they're somehow magic is wrong (and so does Linus, from previous discussions).
Well it would be nice if someone could find out how to do it, but I think that if we want X to be able to get 80% CPU when 2 other CPU hogs are running, you have to renice it.
Quoted 8 lines
OK. So you renice it ... then your two cpu jobs exit, and you kick off xmms. Every time you waggle a window, X will steal the cpu back from xmms, and it'll stall, surely? That's what seemed to happen before. I don't see how you can fix anything by doing static priority alterations (eg nice), because the workload changes.
I'm probably missing something ... feel free to slap me ;-)
OK well just as a rough idea of how mine works: worst case for xmms is that X is at its highest dynamic priority (and reniced). xmms will be at its highest dynamic prio, or maybe one or two below that.
X will get to run for maybe 30ms first, then xmms is allowed 6ms. That is still 15% CPU. And X soon comes down in priority if it continues to use a lot of CPU.
Quoted 14 lines · Nick Piggin
Quoted 9 lines · Martin J. Bligh
OK. So you renice it ... then your two cpu jobs exit, and you kick off xmms. Every time you waggle a window, X will steal the cpu back from xmms, and it'll stall, surely? That's what seemed to happen before. I don't see how you can fix anything by doing static priority alterations (eg nice), because the workload changes.
I'm probably missing something ... feel free to slap me ;-)
Quoted 9 lines
OK well just as a rough idea of how mine works: worst case for xmms is that X is at its highest dynamic priority (and reniced). xmms will be at its highest dynamic prio, or maybe one or two below that.
X will get to run for maybe 30ms first, then xmms is allowed 6ms. That is still 15% CPU. And X soon comes down in priority if it continues to use a lot of CPU.
Backboost is not very different from renicing. It is just and implicit and much less controlled way of allowing unfairness. And that is not very different from the interactivity stuff either.
Quoted 4 lines
I think the two will always related. One means giving a higher dynamic priority, the other a bigger timeslice. So you want say gcc to have a 100ms timeslice with lowest scheduling prio, but X to have a 20ms slice and a very high scheduling priority.
Right.
Quoted 4 lines
Unfortunately, the way the scheduler currently works, X might use all its timeslice, then have to wait 100ms for gcc to finish its. The way I do it is give a small timeslice to high prio tasks, and lower priority tasks get progressively less.
If the interactive task uses all it's timeslice, then it's not really very interactive, it's chewing quite a bit of CPU ... presumably in the common case, these things don't finish their timeslices. I thought we preempted the running task when a higher prio one woke up, so this should still work, right?
So it would seem to make sense to boost the prio of a interactive task *without* increasing the size of it's timeslice.
Quoted 2 lines
When _only_ low priority tasks are running, they'll all get long timeslices.
That at least makes sense. AFIAK at least the early versions of Con's stuff make cpu bound jobs' timeslices short even if there were no interactive jobs. I don't like that (or more relevantly, the benchmarks don't either ;-)).
Quoted 8 lines
OK well just as a rough idea of how mine works: worst case for xmms is that X is at its highest dynamic priority (and reniced). xmms will be at its highest dynamic prio, or maybe one or two below that.
X will get to run for maybe 30ms first, then xmms is allowed 6ms. That is still 15% CPU. And X soon comes down in priority if it continues to use a lot of CPU.
If it works in practice, it works, I guess. I just don't see why X is super special ... are we going to have to renice *all* interactive tasks in order to get things to work properly?
M.
Quoted 44 lines · Martin J. Bligh
Quoted 4 lines
I think the two will always related. One means giving a higher dynamic priority, the other a bigger timeslice. So you want say gcc to have a 100ms timeslice with lowest scheduling prio, but X to have a 20ms slice and a very high scheduling priority.
Right.
Quoted 4 lines
Unfortunately, the way the scheduler currently works, X might use all its timeslice, then have to wait 100ms for gcc to finish its. The way I do it is give a small timeslice to high prio tasks, and lower priority tasks get progressively less.
If the interactive task uses all it's timeslice, then it's not really very interactive, it's chewing quite a bit of CPU ... presumably in the common case, these things don't finish their timeslices. I thought we preempted the running task when a higher prio one woke up, so this should still work, right?
So it would seem to make sense to boost the prio of a interactive task *without* increasing the size of it's timeslice.
Quoted 2 lines
When _only_ low priority tasks are running, they'll all get long timeslices.
That at least makes sense. AFIAK at least the early versions of Con's stuff make cpu bound jobs' timeslices short even if there were no interactive jobs. I don't like that (or more relevantly, the benchmarks don't either ;-)).
Quoted 8 lines
OK well just as a rough idea of how mine works: worst case for xmms is that X is at its highest dynamic priority (and reniced). xmms will be at its highest dynamic prio, or maybe one or two below that.
X will get to run for maybe 30ms first, then xmms is allowed 6ms. That is still 15% CPU. And X soon comes down in priority if it continues to use a lot of CPU.
Quoted 4 lines
If it works in practice, it works, I guess. I just don't see why X
is super special ... are we going to have to renice *all* interactive tasks in order to get things to work properly?M.
If you dont see why X is super special then why is xmms even a part of the discussion? All of this basing scheduling performance on a bloated wannabe winamp makes as much sense as gauging car performance using a van. If this was a purely scheduling problem, then why do other players like alsaplayer and such not suck as bad as xmms when under the exact same priority and all? At least use something without a frontend so that you can limit the possibility that the programmers did something stupid like make decoding dependent on some update to the gui. xmms was coded first and foremost to look and work like winamp. Streamlined - even low latency performance was not a base goal. And outside of these two programs X and some audio player, how are things going to be effected? Forget having to renice certain processes, if i have a video player that say, outputs using X will the video thread get lowered below certain other processes because the audio thread is getting a higher dynamic priority and the video thread uses a lot of cpu (maybe i dont have hw accel). What about video players that dont use theads, they require both a lot of cpu and audio playing performance to stay in sync, will it be dropped below the priority of other apps?
It's early for me so maybe i'm overreacting. I just dont see the logic in using a program like xmms to guage audio playback performance since it's main goal is to be like winamp, not efficiently playback audio and so can be introducing all kinds of performance hits not found in other players.
Quoted 2 lines
If you dont see why X is super special then why is xmms even a part of the discussion?
Because it's an example of why X *isn't* super special - it's just another interactive app. If we have to explicitly boost every interactive app, we're screwed.
Quoted 9 lines
All of this basing scheduling performance on a bloated wannabe winamp
makes as much sense as gauging car performance using a van. If this
was a purely scheduling problem, then why do other players like alsaplayer and such not suck as bad as xmms when under the exact same priority and all? At least use something without a frontend so that you can limit the possibility that the programmers did something stupid like make decoding dependent on some update to the gui.
xmms was coded first and foremost to look and work like winamp. Streamlined - even low latency performance was not a base goal.
The reality is that people use xmms, and whilst it may not be the greatest program known to man, I don't believe it's *that* fundamentally screwed up that it should skip under normal desktop loads. *Especially* if it worked fine under 2.4 ;-)
Some people have observed that ALSA drivers seem worse than the older ones ... I haven't done enough comparisons to be sure that's true, but maybe they have less buffering or something. More buffering in the kernel side might get rid of the sound skips.
Quoted 9 lines
And outside of these two programs X and some audio player, how are
things going to be effected? Forget having to renice certain
processes, if i have a video player that say, outputs using X will the video thread get lowered below certain other processes because the audio thread is getting a higher dynamic priority and the video thread uses a lot of cpu (maybe i dont have hw accel). What about video players that dont use theads, they require both a lot of cpu and audio playing performance to stay in sync, will it be dropped below the priority of other apps?
Don't think that's really so easy to solve, unless you do the hardware boost thing. The original focus seemed to be giving a prio boost to tasks that weren't cpu hogs.
Quoted 5 lines
It's early for me so maybe i'm overreacting. I just dont see the logic in using a program like xmms to guage audio playback performance since it's main goal is to be like winamp, not efficiently playback audio and so can be introducing all kinds of performance hits not found in other players.
People should gague performance by how well we do on the apps they want to run. If people want to run xmms, they'll be interested in how well it works. My main objection to benchmarking like this is (and window wiggle tests) are that they're pretty much subjective, and hard to measure.
Personally, I just use xmms because I've found nothing better, but the the UI does suck. Mostly that's because I'm too idle to look hard (or I have better things to do) and it's good enough. Here is _not_ the place for people to tell me what I should use instead ;-)
M.
Quoted 4 lines · Martin J. Bligh
Some people have observed that ALSA drivers seem worse than the older ones ... I haven't done enough comparisons to be sure that's true, but maybe they have less buffering or something. More buffering in the kernel side might get rid of the sound skips.
At the expense of additional latency. It really weirds you out when the volume, tone, and mute buttons have a full second lag ;)
Quoted 5 lines
People should gague performance by how well we do on the apps they want to run. If people want to run xmms, they'll be interested in how well it works. My main objection to benchmarking like this is (and window wiggle tests) are that they're pretty much subjective, and hard to measure.
I have to admit on my laptop, I've failed to see much subjective improvement since O7 or so, as VM and IO issues have predominated since then. The scheduler is basically powerless and the VM manager only slightly more so when the *proper* fix is probably stick another 256M in. ;)
Either that, or put the XFree86 4.3.0 server on a severe diet - 'ps aux' is reporting that as I type, mine has VSZ=384852 and RSS=64724. Thrown in a mozilla with VSZ=122900 and RSS=47316, and you're just waiting for things to degrade into thrashing.
At least for my laptop, any future performance wins are going to come from elsewhere than the CPU scheduler - I'll pick reiser4, VM manager, and I/O manager as top contenders, with "being able to recompile the CPU hogs with xlc" as a long-shot.. ;)
Quoted 3 lines
Personally, I just use xmms because I've found nothing better, but the the UI does suck. Mostly that's because I'm too idle to look hard (or I have better things to do) and it's good enough.
Amen to that. I point xmms at a bunch of .ogg's, it plays them, and it does so well enough that I've not gotten peeved enough to go find a replacement.
Quoted 8 lines · Martin J. Bligh
Quoted 2 lines
All of this basing scheduling performance on a bloated wannabe winamp makes as much sense as gauging car performance using a van. If this was a purely scheduling problem, then why do other players like alsaplayer and such not suck as bad as xmms when under the exact same priority and all? At least use something without a frontend so that you can limit the possibility that the programmers did something stupid like make decoding dependent on some update to the gui. xmms was coded first and foremost to look and work like winamp. Streamlined - even low latency performance was not a base goal.
The reality is that people use xmms, and whilst it may not be the greatest program known to man, I don't believe it's *that* fundamentally screwed up that it should skip under normal desktop loads. *Especially* if it worked fine under 2.4 ;-)
I agree with Martin here. xmms may not be the smartest music player, but its really sad if it skips on a P4 or Athlon.
Quoted 15 lines · Martin J. Bligh
Quoted 5 lines
I think the two will always related. One means giving a higher dynamic priority, the other a bigger timeslice. So you want say gcc to have a 100ms timeslice with lowest scheduling prio, but X to have a 20ms slice and a very high scheduling priority.
Right.
Quoted 5 lines
Unfortunately, the way the scheduler currently works, X might use all its timeslice, then have to wait 100ms for gcc to finish its. The way I do it is give a small timeslice to high prio tasks, and lower priority tasks get progressively less.
Quoted 6 lines
If the interactive task uses all it's timeslice, then it's not really very interactive, it's chewing quite a bit of CPU ... presumably in the common case, these things don't finish their timeslices. I thought we preempted the running task when a higher prio one woke up, so this should still work, right?
No, you are _very_ right about that.
Quoted 3 lines
So it would seem to make sense to boost the prio of a interactive task *without* increasing the size of it's timeslice.
Well, what I do is boost their priority and make the timeslices of non interactive apps smaller. And sometimes they do need small bursts of using a lot of cpu.
Quoted 16 lines
Quoted 4 lines
When _only_ low priority tasks are running, they'll all get long timeslices.
That at least makes sense. AFIAK at least the early versions of Con's stuff make cpu bound jobs' timeslices short even if there were no interactive jobs. I don't like that (or more relevantly, the benchmarks don't either ;-)).
Quoted 5 lines
OK well just as a rough idea of how mine works: worst case for xmms is that X is at its highest dynamic priority (and reniced). xmms will be at its highest dynamic prio, or maybe one or two below that.
Quoted 8 lines
Quoted 4 lines
X will get to run for maybe 30ms first, then xmms is allowed 6ms. That is still 15% CPU. And X soon comes down in priority if it continues to use a lot of CPU.
If it works in practice, it works, I guess. I just don't see why X
is super special ... are we going to have to renice *all* interactive tasks in order to get things to work properly?
The reason X is special is that it uses a lot of CPU, and it can be continually using a lot of CPU, but it is "interactive" - it probably requires the lowest scheduling latency of any other interactive process because it runs the mouse, screen, keyboard etc, things that obviously can't make use of much buffering, if any.
If you wanted X to be treated as any other process, thats fine, use renice 0. It will be given low priorities when using lots of CPU though.
Quoted 10 lines · Martin J. Bligh
Quoted 3 lines
Well it would be nice if someone could find out how to do it, but I think that if we want X to be able to get 80% CPU when 2 other CPU hogs are running, you have to renice it.
OK. So you renice it ... then your two cpu jobs exit, and you kick off xmms. Every time you waggle a window, X will steal the cpu back from xmms, and it'll stall, surely? That's what seemed to happen before. I don't see how you can fix anything by doing static priority alterations (eg nice), because the workload changes.
Not here with version 10 of Nick's patch, and X reniced to -10. I have not had chance to test v12, but will do tonight when I get home.
Cheers,
Signature · 1 line
Martin Schlemmer