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 <[e-mail]> 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 [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
>