the attached patch (against BK-curr) implements more finegrained timeslice
distribution, without changing the total balance of timeslices, by
recalculating the priority of CPU-bound tasks at a finer granularity, and
by roundrobining tasks. Right now this new granularity is 50 msecs (the
default timeslice for default priority tasks is 100 msecs).
Could people, who can reproduce 'audio skips' kind of problems even with
BK-curr, give this patch a go?
Ingo
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -73,6 +73,7 @@
#define INTERACTIVE_DELTA 2
#define MAX_SLEEP_AVG (10*HZ)
#define STARVATION_LIMIT (10*HZ)
+#define TIMESLICE_GRANULARITY (HZ/20 ?: 1)
#define NODE_THRESHOLD 125
/*
@@ -1259,6 +1260,27 @@ void scheduler_tick(int user_ticks, int
enqueue_task(p, rq->expired);
} else
enqueue_task(p, rq->active);
+ } else {
+ /*
+ * Prevent a too long timeslice allowing a task to monopolize
+ * the CPU. We do this by splitting up the timeslice into
+ * smaller pieces.
+ *
+ * Note: this does not mean the task's timeslices expire or
+ * get lost in any way, they just might be preempted by
+ * another task of equal priority. (one with higher
+ * priority would have preempted this task already.) We
+ * requeue this task to the end of the list on this priority
+ * level, which is in essence a round-robin of tasks with
+ * equal priority.
+ */
+ if (!(p->time_slice % TIMESLICE_GRANULARITY) &&
+ (p->array == rq->active)) {
+ dequeue_task(p, rq->active);
+ set_tsk_need_resched(p);
+ p->prio = effective_prio(p);
+ enqueue_task(p, rq->active);
+ }
}
out:
spin_unlock(&rq->lock);
Well, I don't have an interactivity test ... but ran the kerbench and
SDET standard batch job stuff on the big NUMA-Q box, and it's the same ...
incidentally ... I tested the earlier changes individually, and they
actually made things slightly *faster*. Is cool to see that we're improving
both worlds at once.
M.
--On Monday, March 17, 2003 11:21:33 +0100 Ingo Molnar <[email protected]> wrote:
>
> the attached patch (against BK-curr) implements more finegrained timeslice
> distribution, without changing the total balance of timeslices, by
> recalculating the priority of CPU-bound tasks at a finer granularity, and
> by roundrobining tasks. Right now this new granularity is 50 msecs (the
> default timeslice for default priority tasks is 100 msecs).
>
> Could people, who can reproduce 'audio skips' kind of problems even with
> BK-curr, give this patch a go?
>
> Ingo
>
> --- linux/kernel/sched.c.orig
> +++ linux/kernel/sched.c
> @@ -73,6 +73,7 @@
> #define INTERACTIVE_DELTA 2
> #define MAX_SLEEP_AVG (10*HZ)
> #define STARVATION_LIMIT (10*HZ)
> +#define TIMESLICE_GRANULARITY (HZ/20 ?: 1)
> #define NODE_THRESHOLD 125
>
> /*
> @@ -1259,6 +1260,27 @@ void scheduler_tick(int user_ticks, int
> enqueue_task(p, rq->expired);
> } else
> enqueue_task(p, rq->active);
> + } else {
> + /*
> + * Prevent a too long timeslice allowing a task to monopolize
> + * the CPU. We do this by splitting up the timeslice into
> + * smaller pieces.
> + *
> + * Note: this does not mean the task's timeslices expire or
> + * get lost in any way, they just might be preempted by
> + * another task of equal priority. (one with higher
> + * priority would have preempted this task already.) We
> + * requeue this task to the end of the list on this priority
> + * level, which is in essence a round-robin of tasks with
> + * equal priority.
> + */
> + if (!(p->time_slice % TIMESLICE_GRANULARITY) &&
> + (p->array == rq->active)) {
> + dequeue_task(p, rq->active);
> + set_tsk_need_resched(p);
> + p->prio = effective_prio(p);
> + enqueue_task(p, rq->active);
> + }
> }
> out:
> spin_unlock(&rq->lock);
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
On Mon, 17 Mar 2003 11:21:33 +0100, Ingo Molnar wrote:
> the attached patch (against BK-curr) implements more finegrained timeslice
> distribution, without changing the total balance of timeslices, by
> recalculating the priority of CPU-bound tasks at a finer granularity, and
> by roundrobining tasks. Right now this new granularity is 50 msecs (the
> default timeslice for default priority tasks is 100 msecs).
>
> Could people, who can reproduce 'audio skips' kind of problems even with
> BK-curr, give this patch a go?
>
> Ingo
An enthusiastic, Works For Me (tm)....
Linux version 2.5.64
(gcc version 3.2.2 20030217 (Red Hat Linux 8.0 3.2.2-2))
model name : Pentium III (Coppermine)
stepping : 1
cpu MHz : 647.134
cache size : 256 KB
bogomips : 1277.95
Cheers,
Sean
Ingo Molnar <[email protected]> wrote:
>
>
> the attached patch (against BK-curr) implements more finegrained timeslice
> distribution, without changing the total balance of timeslices, by
> recalculating the priority of CPU-bound tasks at a finer granularity, and
> by roundrobining tasks. Right now this new granularity is 50 msecs (the
> default timeslice for default priority tasks is 100 msecs).
I've been running this on the problematic desktop for a couple of days now.
All interactivity problems are 100% solved. Smooth, fast, responsive,
unjerky, etc. Congratulations and thanks; it is a big win.
The various starvation situations all appear to be fixed.
> Could people, who can reproduce 'audio skips' kind of problems even with
> BK-curr, give this patch a go?
I do not test for multimedia performance and cannot comment on this.
On Tue, Mar 18, 2003 at 09:52:28PM -0800, Andrew Morton wrote:
> > Could people, who can reproduce 'audio skips' kind of problems even with
> > BK-curr, give this patch a go?
>
> I do not test for multimedia performance and cannot comment on this.
Andrew, you're no fun :)
I'll test it on my desktop and see whether things get jerky. More to
come later.
Regards
Josh
--
New PGP public key: 0x27AFC3EE
On Tue, 2003-03-18 at 21:52, Andrew Morton wrote:
> > Could people, who can reproduce 'audio skips' kind of problems even with
> > BK-curr, give this patch a go?
>
> I do not test for multimedia performance and cannot comment on this.
I'm still getting starvation problems. If I run xmms with the "Goom"
visualizer (with the window large enough that it is CPU-bound), then
type a command into a shell window (say, ps), it will not run the
command until I close or shrink the goom window. xmms itself plays
fine, though sometimes it fails to go to the next track, apparently for
the same reason (ie, it starts the next track when I disable the
visualizer).
Goom is available from http://ios.free.fr/?page=projet&quoi=1. It
installs pretty easily if you have xmms installed.
That said, it does seem to be better than previous schedulers (for
example, 64-mm8). It used to starve xmms so much that I couldn't close
operate the UI to turn off the visualizer.
J
At 11:13 PM 3/18/2003 -0800, Jeremy Fitzhardinge wrote:
>On Tue, 2003-03-18 at 21:52, Andrew Morton wrote:
> > > Could people, who can reproduce 'audio skips' kind of problems even with
> > > BK-curr, give this patch a go?
> >
> > I do not test for multimedia performance and cannot comment on this.
>
>I'm still getting starvation problems. If I run xmms with the "Goom"
>visualizer (with the window large enough that it is CPU-bound), then
>type a command into a shell window (say, ps), it will not run the
>command until I close or shrink the goom window. xmms itself plays
>fine, though sometimes it fails to go to the next track, apparently for
>the same reason (ie, it starts the next track when I disable the
>visualizer).
I'm hot on the trail (woof) of this. If I get it working "right", are you
willing to test a patch? I don't want to bug Ingo until I've got something
worth arm waving about ;-)
-Mike
----- Original Message -----
From: Jeremy Fitzhardinge <[email protected]>
Date: 18 Mar 2003 23:13:01 -0800
To: Andrew Morton <[email protected]>
Subject: Re: [patch] sched-2.5.64-D3, more interactivity changes
> I'm still getting starvation problems. If I run xmms with the "Goom"
> visualizer (with the window large enough that it is CPU-bound), then
> type a command into a shell window (say, ps), it will not run the
> command until I close or shrink the goom window. xmms itself plays
> fine, though sometimes it fails to go to the next track, apparently for
> the same reason (ie, it starts the next track when I disable the
> visualizer).
Well, I'm also experiencing starvation problems with CPU-bound
loads. For example, I'm converting all my music collection from
MP3 to OGG, and when using "oggenc" to convert from WAV to
OGG, the system becomes pretty unresponsive: running commands
on a terminal (for example a "ps axf") takes forever, unless you
stop (Ctrl+S) the "oggenc" process.
To avoid this, I had to lower "oggenc" priority using renice. Using
renice <PID> +20 helped with starvation :-)
Thanks!
Felipe
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
----- Original Message -----
From: Mike Galbraith <[email protected]>
Date: Wed, 19 Mar 2003 09:21:00 +0100
To: Jeremy Fitzhardinge <[email protected]>
Subject: Re: [patch] sched-2.5.64-D3, more interactivity changes
> At 11:13 PM 3/18/2003 -0800, Jeremy Fitzhardinge wrote:
> >I'm still getting starvation problems. If I run xmms with the "Goom"
> >visualizer (with the window large enough that it is CPU-bound), then
> >type a command into a shell window (say, ps), it will not run the
> >command until I close or shrink the goom window. xmms itself plays
> >fine, though sometimes it fails to go to the next track, apparently for
> >the same reason (ie, it starts the next track when I disable the
> >visualizer).
>
> I'm hot on the trail (woof) of this. If I get it working "right", are you
> willing to test a patch? I don't want to bug Ingo until I've got something
> worth arm waving about ;-)
I'll do :-)
Felipe
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
On Wed, 2003-03-19 at 00:21, Mike Galbraith wrote:
> I'm hot on the trail (woof) of this. If I get it working "right", are you
> willing to test a patch?
Sure.
J
Hi Everyone,
I like Ingo's round down the sleep time fix. It solves most
of the problems.
I have been chasing a small case it doesn't fix. If you have
a circle of processes passing a token (like the irman test which
is part of contest), the processes can still get to inflated
priorities if they are preempted by other processes.
Consider one of the processes in the circle. It spends most of
its time blocked waiting for its turn to pass the token. With Ingo's
change it doesn't get a sleep time credit because the sleep time
almost always rounds down to zero. But if any of the process in
the loop is delayed (maybe it used its time slice), then all of the
other processes in the chain will get a sleep_avg credit for that
delay time.
Here is the idea I have been playing with (in activate_task):
sync_wake_cycle = 0
if (!in_interrupt()) {
/*
* Detect cycles of synchronous wakeups. This catches
* the old circle of processes passing a token benchmarks.
* If none of the processes ever sleep they should not
* get an interactive bonus.
*/
if (current->sync_wake_leader == p->sync_wake_leader)
sync_wake_cycle = 1;
else if (current->sync_wake_leader)
p->sync_wake_leader = current->sync_wake_leader;
else
p->sync_wake_leader = current;
} else {
p->sync_wake_leader = 0;
}
If sync_wake_cycle is set, don't credit the sleep_avg. If there is an
interactive task in the loop, it will break the loop when it is woken by
a real interrupt.
I hope to get another version of my run_avg based (and overly optimistically
named) self-tuning scheduler out soon.
Jim Houston - Concurrent Computer Corp.