All of lore.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 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.