From: Ingo Molnar <mingo@elte.hu>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Nathan Lynch <nathanl@austin.ibm.com>,
Andrew Morton <akpm@osdl.org>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Zwane Mwaikambo <zwane@linuxpower.ca>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Nick Piggin <piggin@cyberone.com.au>
Subject: [patch] new-task-fix.patch, 2.6.8.1-mm1
Date: Tue, 17 Aug 2004 10:45:10 +0200 [thread overview]
Message-ID: <20040817084510.GA6958@elte.hu> (raw)
In-Reply-To: <1092727147.27274.109.camel@bach>
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
* Rusty Russell <rusty@rustcorp.com.au> wrote:
> Looking through 2.6.8.1-mm1, I see this code which doesn't make sense:
> So, first off, the statements under "if (unlikely(cpu != this_cpu))"
> can be folded into the previous block, since that's under the same
> test. Secondly, why is sleep_avg being set twice to the same thing,
> and why are we happy to adjust it the first time without holding the
> rq lock for current, but the second time we make sure we are holding
> the rq lock? [...]
agreed, this is a bug - the code has rotten somewhat. The attached patch
fixes it. I've also cleaned up the locking and added this_rq, to make
clear when and how we are hopping from one runqueue to another. (this
cleanup would have made the original bug more obvious as well.)
This comes after sched-nonlinear-timeslicespatch.patch in 2.6.8.1-mm1.
Tested on x86.
> [...] recalc_task_prio seems happy to adjust a tasks ->sleep_avg
> without holding any lock at all...
this is not true - we always update ->avg_sleep while holding the lock.
recalc_task_prio() is stricly called with p's runqueue lock held.
Ingo
[-- Attachment #2: new-task-fix.patch --]
[-- Type: text/plain, Size: 1650 bytes --]
Rusty noticed that we update the parent ->avg_sleep without holding the
runqueue lock. Also the code needed cleanups.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -1344,7 +1344,7 @@ void fastcall wake_up_new_task(task_t *
{
unsigned long flags;
int this_cpu, cpu;
- runqueue_t *rq;
+ runqueue_t *rq, *this_rq;
rq = task_rq_lock(p, &flags);
cpu = task_cpu(p);
@@ -1386,8 +1386,15 @@ void fastcall wake_up_new_task(task_t *
} else
/* Run child last */
__activate_task(p, rq);
+ /*
+ * We skip the following code due to cpu == this_cpu
+ *
+ * task_rq_unlock(rq, &flags);
+ * this_rq = task_rq_lock(current, &flags);
+ */
+ this_rq = rq;
} else {
- runqueue_t *this_rq = cpu_rq(this_cpu);
+ this_rq = cpu_rq(this_cpu);
/*
* Not the local CPU - must adjust timestamp. This should
@@ -1399,18 +1406,17 @@ void fastcall wake_up_new_task(task_t *
if (TASK_PREEMPTS_CURR(p, rq))
resched_task(rq->curr);
- current->sleep_avg = JIFFIES_TO_NS(CURRENT_BONUS(current) *
- PARENT_PENALTY / 100 * MAX_SLEEP_AVG / MAX_BONUS);
schedstat_inc(rq, wunt_moved);
- }
-
- if (unlikely(cpu != this_cpu)) {
+ /*
+ * Parent and child are on different CPUs, now get the
+ * parent runqueue to update the parent's ->sleep_avg:
+ */
task_rq_unlock(rq, &flags);
- rq = task_rq_lock(current, &flags);
+ this_rq = task_rq_lock(current, &flags);
}
current->sleep_avg = JIFFIES_TO_NS(CURRENT_BONUS(current) *
PARENT_PENALTY / 100 * MAX_SLEEP_AVG / MAX_BONUS);
- task_rq_unlock(rq, &flags);
+ task_rq_unlock(this_rq, &flags);
}
/*
next prev parent reply other threads:[~2004-08-17 8:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-16 21:37 2.6.8.1-mm1 Andrew Morton
2004-08-16 21:47 ` 2.6.8.1-mm1 Christoph Hellwig
2004-08-17 13:20 ` 2.6.8.1-mm1 Frediano Ziglio
2004-08-18 23:57 ` 2.6.8.1-mm1 Peter Osterlund
2004-08-19 9:45 ` 2.6.8.1-mm1 Christoph Hellwig
2004-08-20 5:44 ` 2.6.8.1-mm1 Peter Osterlund
2004-08-20 6:03 ` 2.6.8.1-mm1 Christoph Hellwig
2004-08-16 22:30 ` 2.6.8.1-mm1 Bartlomiej Zolnierkiewicz
2004-08-16 21:51 ` 2.6.8.1-mm1 Alan Cox
2004-08-16 23:25 ` 2.6.8.1-mm1 Arkadiusz Miskiewicz
2004-08-16 23:39 ` 2.6.8.1-mm1 Martin J. Bligh
2004-08-17 1:32 ` 2.6.8.1-mm1 Nathan Lynch
2004-08-17 6:59 ` 2.6.8.1-mm1 Sam Ravnborg
2004-08-17 6:25 ` 2.6.8.1-mm1 Martin J. Bligh
2004-08-17 6:38 ` 2.6.8.1-mm1 Andrew Morton
2004-08-17 7:00 ` 2.6.8.1-mm1 William Lee Irwin III
2004-08-17 7:05 ` 2.6.8.1-mm1 William Lee Irwin III
2004-08-17 3:07 ` 2.6.8.1-mm1 William Lee Irwin III
2004-08-17 3:09 ` 2.6.8.1-mm1 William Lee Irwin III
2004-08-17 3:19 ` 2.6.8.1-mm1 Andrew Morton
2004-08-17 3:41 ` 2.6.8.1-mm1 William Lee Irwin III
2004-08-17 4:16 ` 2.6.8.1-mm1 Nick Piggin
2004-08-17 14:38 ` 2.6.8.1-mm1 (compile stats) John Cherry
2004-08-17 5:59 ` 2.6.8.1-mm1 Nathan Lynch
2004-08-17 7:19 ` 2.6.8.1-mm1 Rusty Russell
2004-08-17 8:45 ` Ingo Molnar [this message]
2004-08-17 11:35 ` [patch] new-task-fix.patch, 2.6.8.1-mm1 Nick Piggin
2004-08-17 11:38 ` 2.6.8.1-mm1 Srivatsa Vaddagiri
2004-08-17 17:53 ` 2.6.8.1-mm1 Andrew Morton
2004-08-18 1:04 ` 2.6.8.1-mm1 Rusty Russell
2004-08-18 17:36 ` 2.6.8.1-mm1 Nathan Lynch
2004-08-17 6:20 ` 2.6.8.1-mm1 William Lee Irwin III
2004-08-17 6:40 ` 2.6.8.1-mm1 sam
2004-08-17 7:05 ` 2.6.8.1-mm1 Nathan Lynch
2004-08-17 13:39 ` 2.6.8.1-mm1 Zwane Mwaikambo
2004-08-17 12:54 ` 2.6.8.1-mm1 William Lee Irwin III
2004-08-17 14:15 ` 2.6.8.1-mm1 William Lee Irwin III
2004-08-17 21:59 ` ldchk -> arch/arm/Makefile? [Was: 2.6.8.1-mm1] Sam Ravnborg
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=20040817084510.GA6958@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nathanl@austin.ibm.com \
--cc=piggin@cyberone.com.au \
--cc=rusty@rustcorp.com.au \
--cc=vatsa@in.ibm.com \
--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