Re: [patch] sched-2.5.64-D3, more interactivity changes

Re: [patch] sched-2.5.64-D3, more interactivity changes

[Sean Estabrooks]

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

Re: [patch] sched-2.5.64-D3, more interactivity changes

[Jim Houston]

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.

Re: [patch] sched-2.5.64-D3, more interactivity changes

[Jeremy Fitzhardinge]

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

Re: [patch] sched-2.5.64-D3, more interactivity changes

[Felipe Alfaro Solana]

----- Original Message ----- 
From: Mike Galbraith <efault@gmx.de> 
Date: 	Wed, 19 Mar 2003 09:21:00 +0100 
To: Jeremy Fitzhardinge <jeremy@goop.org> 
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

Re: [patch] sched-2.5.64-D3, more interactivity changes

[Felipe Alfaro Solana]

----- Original Message ----- 
From: Jeremy Fitzhardinge <jeremy@goop.org> 
Date: 	18 Mar 2003 23:13:01 -0800 
To: Andrew Morton <akpm@digeo.com> 
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

Re: [patch] sched-2.5.64-D3, more interactivity changes

[Mike Galbraith]

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 

Re: [patch] sched-2.5.64-D3, more interactivity changes

[Jeremy Fitzhardinge]

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

Re: [patch] sched-2.5.64-D3, more interactivity changes

[Joshua Kwan]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch] sched-2.5.64-D3, more interactivity changes

[Andrew Morton]

Ingo Molnar <mingo@elte.hu> 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.

Re: [patch] sched-2.5.64-D3, more interactivity changes

[Martin J. Bligh]

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 <mingo@elte.hu> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

[patch] sched-2.5.64-D3, more interactivity changes

[Ingo Molnar]

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);