From: Mike Galbraith <efault@gmx.de>
To: lkml <linux-kernel@vger.kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@osdl.org>
Subject: [2.6.16-rc6 patch] fix interactive task starvation
Date: Sat, 18 Mar 2006 06:08:00 +0100 [thread overview]
Message-ID: <1142658480.8262.38.camel@homer> (raw)
Greetings,
The patch below fixes a starvation problem that occurs when a stream of
highly interactive tasks delay an array switch for extended periods
despite EXPIRED_STARVING(rq) being true. AFAIKT, the only choice is to
enqueue awakening tasks on the expired array in this case.
Without this patch, it can be nearly impossible to remotely login to a
busy server, and interactive shell commands can starve for minutes.
This has not been verified by anyone. Comments?
-Mike
Signed-off-by: Mike Galbraith <efault@gmx.de>
--- linux-2.6.16-rc6/kernel/sched.c.org 2006-03-17 14:48:35.000000000 +0100
+++ linux-2.6.16-rc6/kernel/sched.c 2006-03-17 17:41:25.000000000 +0100
@@ -662,11 +662,30 @@
}
/*
+ * We place interactive tasks back into the active array, if possible.
+ *
+ * To guarantee that this does not starve expired tasks we ignore the
+ * interactivity of a task if the first expired task had to wait more
+ * than a 'reasonable' amount of time. This deadline timeout is
+ * load-dependent, as the frequency of array switched decreases with
+ * increasing number of running tasks. We also ignore the interactivity
+ * if a better static_prio task has expired:
+ */
+#define EXPIRED_STARVING(rq) \
+ ((STARVATION_LIMIT && ((rq)->expired_timestamp && \
+ (jiffies - (rq)->expired_timestamp >= \
+ STARVATION_LIMIT * ((rq)->nr_running) + 1))) || \
+ ((rq)->curr->static_prio > (rq)->best_expired_prio))
+
+/*
* __activate_task - move a task to the runqueue.
*/
static inline void __activate_task(task_t *p, runqueue_t *rq)
{
- enqueue_task(p, rq->active);
+ prio_array_t *array = rq->active;
+ if (unlikely(EXPIRED_STARVING(rq)))
+ array = rq->expired;
+ enqueue_task(p, array);
rq->nr_running++;
}
@@ -2461,22 +2480,6 @@
}
/*
- * We place interactive tasks back into the active array, if possible.
- *
- * To guarantee that this does not starve expired tasks we ignore the
- * interactivity of a task if the first expired task had to wait more
- * than a 'reasonable' amount of time. This deadline timeout is
- * load-dependent, as the frequency of array switched decreases with
- * increasing number of running tasks. We also ignore the interactivity
- * if a better static_prio task has expired:
- */
-#define EXPIRED_STARVING(rq) \
- ((STARVATION_LIMIT && ((rq)->expired_timestamp && \
- (jiffies - (rq)->expired_timestamp >= \
- STARVATION_LIMIT * ((rq)->nr_running) + 1))) || \
- ((rq)->curr->static_prio > (rq)->best_expired_prio))
-
-/*
* Account user cpu time to a process.
* @p: the process that the cpu time gets accounted to
* @hardirq_offset: the offset to subtract from hardirq_count()
next reply other threads:[~2006-03-18 5:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-18 5:08 Mike Galbraith [this message]
2006-03-18 5:15 ` [2.6.16-rc6 patch] fix interactive task starvation Andrew Morton
2006-03-18 5:50 ` Mike Galbraith
2006-03-18 6:22 ` Andrew Morton
2006-03-18 7:29 ` Mike Galbraith
2006-03-18 7:33 ` Andrew Morton
2006-03-18 7:48 ` Mike Galbraith
2006-03-18 7:52 ` Andrew Morton
2006-03-18 8:51 ` Ingo Molnar
2006-03-18 8:05 ` Andrew Morton
2006-03-18 8:15 ` Con Kolivas
2006-03-18 9:43 ` Mike Galbraith
2006-03-18 8:52 ` Ingo Molnar
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=1142658480.8262.38.camel@homer \
--to=efault@gmx.de \
--cc=akpm@osdl.org \
--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.