We don't want to allow a cpu going offline to keep doing scheduler work so
let it exit early, otherwise we'd keep pulling in tasks every timer tick.
diff -u -r1.1.1.1 sched.c
--- linux-2.5.61-trojan/kernel/sched.c 15 Feb 2003 12:32:44 -0000 1.1.1.1
+++ linux-2.5.61-trojan/kernel/sched.c 15 Feb 2003 16:04:51 -0000
@@ -939,6 +948,11 @@
struct list_head *head, *curr;
task_t *tmp;
+ /* CPU going down is a special case: we don't pull more tasks
+ onboard */
+ if (unlikely(!cpu_online(this_cpu)))
+ goto out;
+
busiest = find_busiest_queue(this_rq, this_cpu, idle, &imbalance,
cpus_to_balance(this_cpu, this_rq));
if (!busiest)
On Mon, 17 Feb 2003, Zwane Mwaikambo wrote:
> We don't want to allow a cpu going offline to keep doing scheduler work
> so let it exit early, otherwise we'd keep pulling in tasks every timer
> tick.
i'd rather have all the hotplug CPU code to do this kind of stuff
completely out of line. Start up a max-RT-priority housekeeping task and
just clean the runqueue and deregister the CPU in one atomic pass - look
at how the migration threads do similar stuff. No need to contaminate
various codepaths with 'is this CPU online' checks.
Ingo
On Mon, 17 Feb 2003, Ingo Molnar wrote:
>
> On Mon, 17 Feb 2003, Zwane Mwaikambo wrote:
>
> > We don't want to allow a cpu going offline to keep doing scheduler work
> > so let it exit early, otherwise we'd keep pulling in tasks every timer
> > tick.
>
> i'd rather have all the hotplug CPU code to do this kind of stuff
> completely out of line. Start up a max-RT-priority housekeeping task and
> just clean the runqueue and deregister the CPU in one atomic pass - look
> at how the migration threads do similar stuff. No need to contaminate
> various codepaths with 'is this CPU online' checks.
Ok for this we'll have to move the task migration down till after the cpu
has gone completely offline ie dead, then pull the tasks off the dead
runqueue. I'm not aware of any ill effects of such a move.
Zwane
--
function.linuxpower.ca