From: "Dmitry Adamushko" <dmitry.adamushko@gmail.com>
To: "Ingo Molnar" <mingo@elte.hu>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: [PATCH] [sched] redundant reschedule when set_user_nice() boosts a prio of a task from the "expired" array
Date: Wed, 4 Apr 2007 22:05:40 +0200 [thread overview]
Message-ID: <b647ffbd0704041305t2a140369q56cf9f0746b8fd86@mail.gmail.com> (raw)
In-Reply-To: <20070404141546.GA862@elte.hu>
Ingo,
following the conversation on "a redundant reschedule call in set_user_prio()",
here is a possible approach.
The patch is somewhat intrusive as it even dares to adapt TASK_PREEMPTS_CURR().
Nevertheless, this adaptation seems to be ok with all the current use-cases.
Presupposition: TASK_PREEMPTS_CURR(p, rq) will /never/ be used as "a
mere prio comparator" - e.g. to make decisions on which array a task
has to be placed in.
=====
o Make TASK_PREEMPTS_CURR(task, rq) return "true" only if the task's
prio is higher than the current's one and the task is in the "active"
array.
This ensures we don't make redundant resched_task() calls when the
task is in the "expired" array (as may happen now in set_user_prio(),
rt_mutex_setprio() and pull_task() ) ;
o generilise conditions for a call to resched_task() in
set_user_nice(), rt_mutex_setprio() and sched_setscheduler()
Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com>
--
--- linux-2.6.21-rc5/kernel/sched-orig.c 2007-04-04
18:26:19.000000000 +0200
+++ linux-2.6.21-rc5/kernel/sched.c 2007-04-04 18:26:43.000000000 +0200
@@ -168,7 +168,7 @@ unsigned long long __attribute__((weak))
(MAX_BONUS / 2 + DELTA((p)) + 1) / MAX_BONUS - 1))
#define TASK_PREEMPTS_CURR(p, rq) \
- ((p)->prio < (rq)->curr->prio)
+ (((p)->prio < (rq)->curr->prio) && ((p)->array == (rq)->active))
#define SCALE_PRIO(x, prio) \
max(x * (MAX_PRIO - prio) / (MAX_USER_PRIO / 2), MIN_TIMESLICE)
@@ -3847,13 +3847,13 @@ void rt_mutex_setprio(struct task_struct
struct prio_array *array;
unsigned long flags;
struct rq *rq;
- int oldprio;
+ int delta;
BUG_ON(prio < 0 || prio > MAX_PRIO);
rq = task_rq_lock(p, &flags);
- oldprio = p->prio;
+ delta = prio - p->prio;
array = p->array;
if (array)
dequeue_task(p, array);
@@ -3869,13 +3869,10 @@ void rt_mutex_setprio(struct task_struct
enqueue_task(p, array);
/*
* Reschedule if we are currently running on this runqueue and
- * our priority decreased, or if we are not currently running on
- * this runqueue and our priority is higher than the current's
+ * our priority decreased, or if our priority became higher
+ * than the current's.
*/
- if (task_running(rq, p)) {
- if (p->prio > oldprio)
- resched_task(rq->curr);
- } else if (TASK_PREEMPTS_CURR(p, rq))
+ if (TASK_PREEMPTS_CURR(p, rq) || (delta > 0 &&
task_running(rq, p)))
resched_task(rq->curr);
}
task_rq_unlock(rq, &flags);
@@ -3923,10 +3920,11 @@ void set_user_nice(struct task_struct *p
enqueue_task(p, array);
inc_raw_weighted_load(rq, p);
/*
- * If the task increased its priority or is running and
- * lowered its priority, then reschedule its CPU:
+ * Reschedule if we are currently running on this runqueue and
+ * our priority decreased, or if our priority became higher
+ * than the current's.
*/
- if (delta < 0 || (delta > 0 && task_running(rq, p)))
+ if (TASK_PREEMPTS_CURR(p, rq) || (delta > 0 &&
task_running(rq, p)))
resched_task(rq->curr);
}
out_unlock:
@@ -4153,13 +4151,10 @@ recheck:
__activate_task(p, rq);
/*
* Reschedule if we are currently running on this runqueue and
- * our priority decreased, or if we are not currently running on
- * this runqueue and our priority is higher than the current's
+ * our priority decreased, or our priority became higher
+ * than the current's.
*/
- if (task_running(rq, p)) {
- if (p->prio > oldprio)
- resched_task(rq->curr);
- } else if (TASK_PREEMPTS_CURR(p, rq))
+ if (TASK_PREEMPTS_CURR(p, rq) || (task_running(rq, p)
&& p->prio > oldprio))
resched_task(rq->curr);
}
__task_rq_unlock(rq);
=====
--
Best regards,
Dmitry Adamushko
next prev parent reply other threads:[~2007-04-04 20:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-04 14:04 Dmitry Adamushko
2007-04-04 14:15 ` Ingo Molnar
2007-04-04 15:23 ` Dmitry Adamushko
2007-04-04 20:05 ` Dmitry Adamushko [this message]
2007-04-07 0:03 ` [PATCH] " Andrew Morton
2007-04-07 9:16 ` Dmitry Adamushko
2007-04-07 9:24 ` Ingo Molnar
2007-04-07 16:20 ` SD scheduler testing hitch Mike Galbraith
2007-04-07 17:17 ` Mike Galbraith
2007-04-08 8:02 ` Mike Galbraith
2007-04-09 0:14 ` Dmitry Adamushko
2007-04-09 0:23 ` Dmitry Adamushko
2007-04-09 5:54 ` Mike Galbraith
2007-04-07 9:19 ` [PATCH] [sched] redundant reschedule when set_user_nice() boosts a prio of a task from the "expired" array 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=b647ffbd0704041305t2a140369q56cf9f0746b8fd86@mail.gmail.com \
--to=dmitry.adamushko@gmail.com \
--cc=akpm@linux-foundation.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
all inboxes | Powered by JetHome®