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/
>
>
next prev parent 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