public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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);
 }
 
 /*

  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