All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.