public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Ingo Molnar <mingo@elte.hu>, linux-kernel@vger.kernel.org
Cc: Mike Galbraith <efault@gmx.de>, Andrew Morton <akpm@zip.com.au>
Subject: Re: [patch] sched-2.5.64-D3, more interactivity changes
Date: Mon, 17 Mar 2003 10:01:34 -0800	[thread overview]
Message-ID: <268320000.1047924094@flay> (raw)
In-Reply-To: <Pine.LNX.4.44.0303171114310.19107-100000@localhost.localdomain>

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/
> 
> 



  reply	other threads:[~2003-03-17 18:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-17 10:21 [patch] sched-2.5.64-D3, more interactivity changes Ingo Molnar
2003-03-17 18:01 ` Martin J. Bligh [this message]
2003-03-19  5:52 ` Andrew Morton
2003-03-19  6:31   ` Joshua Kwan
2003-03-19  7:13   ` Jeremy Fitzhardinge
2003-03-19  8:21     ` Mike Galbraith
2003-03-19 16:37       ` Jeremy Fitzhardinge
2003-03-19 16:51       ` Jim Houston
  -- strict thread matches above, loose matches on Subject: below --
2003-03-18  0:28 Sean Estabrooks
2003-03-19 11:30 Felipe Alfaro Solana
2003-03-19 11:40 Felipe Alfaro Solana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=268320000.1047924094@flay \
    --to=mbligh@aracnet.com \
    --cc=akpm@zip.com.au \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox