From: Con Kolivas <kernel@kolivas.org>
To: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>,
Zwane Mwaikambo <zwane@linuxpower.ca>
Cc: Andreas Boman <aboman@midgaard.us>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Mike Galbraith <efault@gmx.de>
Subject: Re: [PATCH] sleep_decay for interactivity 2.5.72 - testers needed
Date: Mon, 23 Jun 2003 07:37:17 +1000 [thread overview]
Message-ID: <200306230737.17766.kernel@kolivas.org> (raw)
In-Reply-To: <200306230724.39194.kernel@kolivas.org>
[-- Attachment #1: Type: text/plain, Size: 2803 bytes --]
On Mon, 23 Jun 2003 07:24, Con Kolivas wrote:
> On Mon, 23 Jun 2003 02:14, Felipe Alfaro Solana wrote:
> > On Sun, 2003-06-22 at 17:58, Con Kolivas wrote:
> > > On Mon, 23 Jun 2003 01:40, Felipe Alfaro Solana wrote:
> > > > On Sun, 2003-06-22 at 15:45, Con Kolivas wrote:
> > > > > > Feel free to test it and comment. Things to look for - the
> > > > > > dreaded audio skip under load, and X remaining interactive during
> > > > > > sustained use under load.
> > > >
> > > > I must say this seems to be getting better, but I still prefer Mike's
> > > > patches. With the latest sleep decay patch and 2.5.72-mm3, I can
> > > > still easily starve XMMS audio for a long time (~5 seconds) on my
> > > > 700Mhz Pentium III laptoñ (running RHL9 and KDE 3.1.2) simply by
> > > > running "while true; do a=2; done" on a konsole window. Dragging a
> > > > window fast enough also starves XMMS for ~5 seconds just until the
> > > > scheduler adjusts the priorities.
> > > >
> > > > XMMS is running with an effective priority of 15 (that's what top
> > > > says). "while true; do a=2; done" starts with a priority of 15 (which
> > > > causes XMMS to stop playing sound), then it is detected as a CPU hog
> > > > and every second its priority is increased by one. When its priority
> > > > reaches 20, XMMS starts playing again.
> > > >
> > > > When I move windows around fast enough. the X server starts with a
> > > > priority of 15, starving XMMS. If I keep moving windows around for a
> > > > long time, X's priority starts increasing by one, until it reaches
> > > > 20. At this moment, it stops disturbing XMMS audio playback.
> > > >
> > > > I've been playing with scheduler parameters, mainly by reducing
> > > > MAX_SLEEP_AVG to (HZ) and STARVATION_LIMIT to (HZ). This seems to
> > > > help a lot, although I can still make XMMS skip sound every once a
> > > > bit. However, mplayer is a really hard one: I have been unable to
> > > > make it skip sound yet.
> > >
> > > Yes Mike's patches are definitely better. My patches are designed for
> > > the 2.4-ck patchset which has other workarounds that augment this
> > > patch; however these workarounds are harder to stomach for mainstream
> > > kernels (read nasty hacks). I thought I'd offer the not so nasty
> > > sleep_decay patch in 2.5 form for perusal and comments since people are
> > > more willing to test 2.5 patches.
> >
> > Well, it's nice to know.
> > I'm willing to test nearly any 2.5 patch. So, I'll gladly test any other
> > ideas or patches you (or others) might have.
>
> ANY?
>
> Ok well I guess I have to give away my secret then. This is the change that
> turns 2.5 into a desktop kernel. Note the very slight change to Ingo's
> addon ;-)
Damn did it again.
Here's the real one.
[-- Attachment #2: patch-o1int-9396230736 --]
[-- Type: text/x-diff, Size: 3364 bytes --]
diff -Naurp linux-2.5.72/include/linux/sched.h linux-2.5.72-test/include/linux/sched.h
--- linux-2.5.72/include/linux/sched.h 2003-06-18 22:47:19.000000000 +1000
+++ linux-2.5.72-test/include/linux/sched.h 2003-06-19 20:56:18.000000000 +1000
@@ -332,6 +332,7 @@ struct task_struct {
unsigned long sleep_avg;
unsigned long last_run;
+ unsigned long best_sleep_avg;
unsigned long policy;
unsigned long cpus_allowed;
--- linux-2.5.72/kernel/sched.c 2003-06-18 22:47:25.000000000 +1000
+++ linux-2.5.72-test/kernel/sched.c 2003-06-23 07:21:07.000000000 +1000
@@ -72,7 +72,8 @@
#define EXIT_WEIGHT 3
#define PRIO_BONUS_RATIO 25
#define INTERACTIVE_DELTA 2
-#define MAX_SLEEP_AVG (10*HZ)
+#define MAX_SLEEP_AVG (2 * HZ)
+#define BEST_SLEEP_DECAY (10)
#define STARVATION_LIMIT (10*HZ)
#define NODE_THRESHOLD 125
@@ -313,12 +314,22 @@ static inline void enqueue_task(struct t
*/
static int effective_prio(task_t *p)
{
- int bonus, prio;
+ int bonus, prio, neg_flag = 1, scale = MAX_SLEEP_AVG / 2;
if (rt_task(p))
return p->prio;
- bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*p->sleep_avg/MAX_SLEEP_AVG/100 -
+ bonus = p->best_sleep_avg/BEST_SLEEP_DECAY;
+ if (bonus > MAX_SLEEP_AVG) bonus = MAX_SLEEP_AVG;
+
+ bonus -= scale;
+ if (bonus < 0) neg_flag = -1;
+ bonus *= bonus;
+ bonus /= scale;
+ bonus *= neg_flag;
+ bonus += scale;
+
+ bonus = MAX_USER_PRIO*PRIO_BONUS_RATIO*bonus/MAX_SLEEP_AVG/100 -
MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
prio = p->static_prio - bonus;
@@ -371,6 +382,8 @@ static inline void activate_task(task_t
sleep_avg = MAX_SLEEP_AVG;
if (p->sleep_avg != sleep_avg) {
p->sleep_avg = sleep_avg;
+ if ((sleep_avg * BEST_SLEEP_DECAY) > p->best_sleep_avg)
+ p->best_sleep_avg = sleep_avg * (BEST_SLEEP_DECAY + 1) - 1;
p->prio = effective_prio(p);
}
}
@@ -551,6 +564,7 @@ void wake_up_forked_process(task_t * p)
*/
current->sleep_avg = current->sleep_avg * PARENT_PENALTY / 100;
p->sleep_avg = p->sleep_avg * CHILD_PENALTY / 100;
+ p->best_sleep_avg = p->sleep_avg * (BEST_SLEEP_DECAY + 1) - 1;
p->prio = effective_prio(p);
set_task_cpu(p, smp_processor_id());
@@ -1200,6 +1214,8 @@ void scheduler_tick(int user_ticks, int
*/
if (p->sleep_avg)
p->sleep_avg--;
+ if (p->best_sleep_avg)
+ p->best_sleep_avg--;
if (unlikely(rt_task(p))) {
/*
* RR tasks need a special form of timeslice management.
@@ -1229,6 +1245,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 % MIN_TIMESLICE) &&
+ (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_unlock:
spin_unlock(&rq->lock);
next prev parent reply other threads:[~2003-06-22 21:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-19 14:05 [PATCH] sleep_decay for interactivity 2.5.72 - testers needed Con Kolivas
2003-06-19 15:47 ` Mike Galbraith
2003-06-19 15:51 ` Con Kolivas
2003-06-19 16:02 ` Con Kolivas
2003-06-19 16:06 ` Con Kolivas
2003-06-19 16:42 ` Andreas Boman
2003-06-19 16:50 ` Con Kolivas
[not found] ` <1056058342.917.69.camel@asgaard.midgaard.us>
2003-06-20 2:29 ` Con Kolivas
2003-06-20 11:09 ` Mike Galbraith
2003-06-22 13:35 ` Con Kolivas
2003-06-22 13:45 ` Con Kolivas
2003-06-22 15:40 ` Felipe Alfaro Solana
2003-06-22 15:58 ` Con Kolivas
2003-06-22 16:14 ` Felipe Alfaro Solana
2003-06-22 21:24 ` Con Kolivas
2003-06-22 21:37 ` Con Kolivas [this message]
2003-06-23 11:16 ` Felipe Alfaro Solana
2003-06-23 11:21 ` Con Kolivas
2003-06-19 17:31 ` Mike Galbraith
2003-06-19 18:51 ` Andreas Boman
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=200306230737.17766.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=aboman@midgaard.us \
--cc=efault@gmx.de \
--cc=felipe_alfaro@linuxmail.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zwane@linuxpower.ca \
/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