From: Mike Galbraith <efault@gmx.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu
Subject: Re: [2.6.16-rc6 patch] fix interactive task starvation
Date: Sat, 18 Mar 2006 08:29:45 +0100 [thread overview]
Message-ID: <1142666985.7881.5.camel@homer> (raw)
In-Reply-To: <20060317222203.06d7f450.akpm@osdl.org>
On Fri, 2006-03-17 at 22:22 -0800, Andrew Morton wrote:
> Mike Galbraith <efault@gmx.de> wrote:
> >
> > > Does this have to be a macro?
> > >
> >
> > I suppose not, now inlined.
> >
>
> It would be nice to uninline the function and then to modify it in a
> followup patch. That way, we get to see what changed, which is one of the
> reasons to not use megamacros (sorry).
Ok, take 3 below, with updated main comment as well.
> The function returns a boolean, so we should short-circuit the evaluation
> where possible.
Done.
-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-18 08:03:34.000000000 +0100
@@ -662,11 +662,56 @@
}
/*
+ * 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, and switch periodically
+ * regardless, to ensure that highly interactive tasks do not starve
+ * the less fortunate for unreasonably long periods.
+ */
+static int expired_starving(runqueue_t *rq)
+{
+ int limit;
+
+ /*
+ * Arrays were recently switched, all is well.
+ */
+ if (!rq->expired_timestamp)
+ return 0;
+
+ limit = STARVATION_LIMIT * rq->nr_running;
+
+ /*
+ * It's time to switch arrays.
+ */
+ if (jiffies - rq->expired_timestamp >= limit)
+ return 1;
+
+ /*
+ * There's a better selection in the expired array.
+ */
+ if (rq->curr->static_prio > rq->best_expired_prio)
+ return 1;
+
+ /*
+ * All is well.
+ */
+ return 0;
+}
+
+/*
* __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 +2506,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()
@@ -2611,7 +2640,7 @@
if (!rq->expired_timestamp)
rq->expired_timestamp = jiffies;
- if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq)) {
+ if (!TASK_INTERACTIVE(p) || expired_starving(rq)) {
enqueue_task(p, rq->expired);
if (p->static_prio < rq->best_expired_prio)
rq->best_expired_prio = p->static_prio;
next prev parent reply other threads:[~2006-03-18 7:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-18 5:08 [2.6.16-rc6 patch] fix interactive task starvation Mike Galbraith
2006-03-18 5:15 ` Andrew Morton
2006-03-18 5:50 ` Mike Galbraith
2006-03-18 6:22 ` Andrew Morton
2006-03-18 7:29 ` Mike Galbraith [this message]
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=1142666985.7881.5.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox